These postings are provided "AS IS" with no warranties, and confer no rights. Use of included code samples are subject to the terms specified at Microsoft -
Notes on comments.
Welcome to our blog dedicated to the engineering of Microsoft Windows 7
We’re busy going through tons of telemetry from the many people that have downloaded and installed the Windows 7 beta around the world. We’re super excited to see the excitement around kicking the tires. Since most folks on the beta are well-versed in the hardware they use and very tuned into the choices they make, we’ve received a few questions about the Windows Experience Index (WEI) in Windows 7 and how that has been changed and improved in Windows 7 to take into account new hardware available for each of the major classes in the metric. In this post Michael Fortin returns to dive into the engineering details of the WEI.
The WEI was introduced in Windows Vista to provide one means across PCs to measure the relative performance of key hardware components. Like any index or benchmark, it is best used as a relative measure and should not be used to compare one measure to another. Unlike many other measures, the WEI merely measures the relative capability of components. The WEI only runs for a short time and does not measure the interactions of components under a software load, but rather characteristics or your hardware. As such it does not (nor cannot) measure how a system will perform under the your own usage scenarios. Thus the WEI does not measure performance of a system, but merely the relative hardware capabilities when running Windows 7.
We do want to caution folks in trying to generalize an “absolute” WEI as necessary for a given individual. We each have different tolerances or more importantly expectations for how a PC should perform and the same WEI might mean very different things to different individuals. To personalize this, I do about 90% of my work on a PC with a WEI of 2.0, primarily driven by the relatively low score for the gaming graphics component on my very low cost laptop. I run Outlook (with ~2GB of email), Internet Explorer (with a dozen tabs), Excel (with longs list of people on the development team), PowerPoint, Messenger (with video), and often I am running one of several LOB applications written in .NET. I feel with this type of workload and a PC with Windows 7 and that WEI my own brain and fingers continues to be my “bottleneck”. At the other end of the spectrum is my holiday gift machine which is a 25” all-in-one with a WEI of 5.1 (though still limited by gaming graphics, with subscores of 7.2, 7.2, 6.2, 5.1, 5.9). This machine runs Windows 7 64-bit and I definitely don’t keep it very busy even though I run MediaCenter in a window all the time, have a bunch of desktop gadgets, and run the PC as our print server (I use about 25% of available RAM and the CPU almost never gets above 10%).
The overall Windows Experience Index (WEI) is defined to be the lowest of the five top-level WEI subscores, where each subscore is computed using a set of rules and a suite of system assessment tests. The five areas scored in Windows 7 are the same as they were in Vista and include:
Though the scoring areas are the same, the ranges have changed. In Vista, the WEI scores ranged from 1.0 to 5.9. In Windows 7, the range has been extended upward to 7.9. The scoring rules for devices have also changed from Vista to reflect experience and feedback comparing closely rated devices with differing quality of actual use (i.e. to make the rating more indicative of actual use.) We know during the beta some folks have noticed that the score changed (relative to Vista) for one or more components in their system and this tuning, which we will describe here, is responsible for the change.
For a given score range, we hope our customers will be able to utilize some general guidelines to help understand the experiences a particular PC can be expected to deliver well, relatively speaking. These Vista-era general guidelines for systems in the 1.0, 2.0, 3.0, 4.0 and 5.0 ranges still apply to Windows 7. But, as noted above, Windows 7 has added levels 6.0 and 7.0; meaning 7.9 is the maximum score possible. These new levels were designed to capture the rather substantial improvements we are seeing in key technologies as they enter the mainstream, such as solid state disks, multi-core processors, and higher end graphics adapters. Additionally, the amount of memory in a system is a determining factor.
For these new levels, we’re working to add guidelines for each level. As an example for gaming users, we expect systems with gaming graphics scores in the 6.0 to 6.9 range to support DX10 graphics and deliver good frames rates at typical screen resolutions (like 40-50 frames per second at 1280x1024). In the range of 7.0 to 7.9, we would expect higher frame rates at even higher screen resolutions. Obviously, the specifics of each game have much to do with this and the WEI scores are also meant to help game developers decide how best to scale their experience on a given system. Graphics is an area where there is both the widest variety of scores readily available in hardwaren and also the widest breadth of expectations. The extremes at which CAD, HD video, photography, and gamers push graphics compared to the average business user or a consumer (doing many of these same things as an avocation rather than vocation) is significant.
Of course, adding new levels doesn’t explain why a Vista system or component that used to score 4.0 or higher is now obtaining a score of 2.9. In most cases, large score drops will be due to the addition of some new disk tests in Windows 7 as that is where we’ve seen both interesting real world learning and substantial changes in the hardware landscape.
With respect to disk scores, as discussed in our recent post on Windows Performance, we’ve been developing a comprehensive performance feedback loop for quite some time. With that loop, we’ve been able to capture thousands of detailed traces covering periods of time where the computer’s current user indicated an application, or Windows, was experiencing severe responsiveness problems. In analyzing these traces we saw a connection to disk I/O and we often found typical 4KB disk reads to take longer than expected, much, much longer in fact (10x to 30x). Instead of taking 10s of milliseconds to complete, we’d often find sequences where individual disk reads took many hundreds of milliseconds to finish. When sequences of these accumulate, higher level application responsiveness can suffer dramatically.
With the problem recognized, we synthesized many of the I/O sequences and undertook a large study on many, many disk drives, including solid state drives. While we did find a good number of drives to be excellent, we unfortunately also found many to have significant challenges under this type of load, which based on telemetry is rather common. In particular, we found the first generation of solid state drives to be broadly challenged when confronted with these commonly seen client I/O sequences.
An example problematic sequence consists of a series of sequential and random I/Os intermixed with one or more flushes. During these sequences, many of the random writes complete in unrealistically short periods of time (say 500 microseconds). Very short I/O completion times indicate caching; the actual work of moving the bits to spinning media, or to flash cells, is postponed. After a period of returning success very quickly, a backlog of deferred work is built up. What happens next is different from drive to drive. Some drives continue to consistently respond to reads as expected, no matter the earlier issued and postponed writes/flushes, which yields good performance and no perceived problems for the person using the PC. Some drives, however, reads are often held off for very lengthy periods as the drives apparently attempt to clear their backlog of work and this results in a perceived “blocking” state or almost a “locked system”. To validate this, on some systems, we replaced poor performing disks with known good disks and observed dramatically improved performance. In a few cases, updating the drive’s firmware was sufficient to very noticeably improve responsiveness.
To reflect this real world learning, in the Windows 7 Beta code, we have capped scores for drives which appear to exhibit the problematic behavior (during the scoring) and are using our feedback system to send back information to us to further evaluate these results. Scores of 1.9, 2.0, 2.9 and 3.0 for the system disk are possible because of our current capping rules. Internally, we feel confident in the beta disk assessment and these caps based on the data we have observed so far. Of course, we expect to learn from data coming from the broader beta population and from feedback and conversations we have with drive manufacturers.
For those obtaining low disk scores but are otherwise satisfied with the performance, we aren’t recommending any action (Of course the WEI is not a tool to recommend hardware changes of any kind). It is entirely possible that the sequence of I/Os being issued for your common workload and applications isn’t encountering the issues we are noting. As we’ve said, the WEI is a metric but only you can apply that metric to your computing needs.
Earlier, I made note of the fact that our new levels, 6 and 7, were added to recognize the improved experiences one might have with newer hardware, particularly SSDs, graphics adapters, and multi-core processors. With respect to SSDs, the focus of the newer tests is on random I/O rates and their avoidance of the long latency issues noted above. As a note, the tests don’t specifically check to see if the underlying storage device is an SSD or not. We run them no matter the device type and any device capable of sustaining very high random I/O rates will score well.
For graphics adapters, both DX9 and DX10 assessments can be run now. In Vista, the tests were specific to DX9. To obtain scores in the 6 or 7 ranges, a graphics adapter must obtain very good performance scores, support DX10 and the driver must be a WDDM 1.1 driver (which you might have noticed are being downloaded in beta during the Windows 7 beta). For WDDM 1.0 drivers, only the DX9 assessments will be run, thus capping the overall score at 5.9.
For multi-core processors, both single threaded and multi-threaded scenarios are run. With levels 6 and 7, we aim to indicate that these systems will be rarely CPU bound for typical use and quite suitable for demanding processing tasks and multi-tasking. As examples, we anticipate many quad core processors will be able to score in the high 6 to low 7 ranges, and 8 core systems to be able to approach 7.9. The scoring has taken into account the very latest micro-processors available.
For many key hardware partners, we’ve of course made available additional details on the changes and why they were made. We continue to actively work with them to incorporate appropriate feedback.
Aka: A developers view of the Windows 7 Engineering process
This post is by Larry Osterman. Larry is one of the most “experienced” developers on the Windows team and has been at Microsoft since the mid 1980’s. There are only three other folks who have worked at Microsoft longer on the entire Windows team! Personally, I remember knowing about Larry when I started at Microsoft back in 1989—I remember he worked on “multimedia” (back when we used to host the Microsoft CD-ROM Conference) and he was one of those people that stood up and received a “5 Year” award from Bill Gates at the first company meeting I went to—that seemed amazing back then! For Windows 7, Larry is a developer on the Devices and Media team which is where we work on audio, video, bluetooth, and all sorts of cool features for connecting up devices to Windows.
Larry wrote this post without any prodding and given his experience on so many Windows releases these thoughts seemed really worthwhile in terms of sharing with folks. This post goes into “how” we work as a team, which for anyone part of a software team might prove pretty interesting. While this is compared and contrasted with Vista, everyone knows that there is no perfect way to do things and this is just a little well-informed perspective.
So thank you Larry! --Steven
Thanks to Steven and Jon for letting me borrow their soapbox :-).
I wanted to discuss my experiences working on building Windows 7 (as opposed to the other technical stuff that you’ve read on this blog so far), and to contrast that with my experiences building Windows Vista. Please note that these are MY experiences. Others will have had different experiences; hopefully they will also share their stories here.
The experience of building Windows 7 is dramatically different from the experience of building Vista. The rough outlines of the product development process haven’t changed, but organizationally, the Windows 7 process is dramatically better.
For Windows Vista, I was a part of the WAVE (Windows Audio Video Excellence) group. The group was led by a general manager who was ultimately responsible for the deliverables. There was a test lead, a development lead and a program management lead who reported to the general manager. The process of building a feature roughly worked like this: the lead program managers decided (based on criteria which aren’t relevant to the post) which features would be built for Windows and which program managers would be responsible for which feature. The development leads decided which developers on the team would be responsible for the feature. The program manager for the feature wrote a functional specification (which described the feature and how it should work) in conjunction with development. Note that the testers weren’t necessarily involved in this part of the process. The developer(s) responsible for the feature wrote the design specification (which described how the feature was going to be implemented). The testers associated with the feature then wrote a test plan which described how to test the feature. The program manager or the developer also wrote the threat model for the feature.
The developer then went off to code the feature, the PM spent their time making sure that the feature was on track, and when the developer was done, the tester started writing test cases.
Once the feature was coded and checked into the source tree, it moved its way up to the “winmain” branch. Aside: The Windows source code has been arranged into “branches” – the root is “winmain”, which is the code base that would ultimately become Windows Vista. Each developer works in what are called “feature branches”, which merge changes into “aggregation branches”, the aggregation branches move into winmain.
After the feature was coded, the testers tested, the developers fixed bugs and the program managers managed the program :-). As the product moved further along, it got harder and harder to get bug fixes checked into winmain (every bug fix carries with it a chance that the fix will introduce a regression, so the risk associated with each bug fix needs to be measured and the tolerance for risk decreases incrementally). The team responsible for managing this process met in the “ship room” where they made decisions every single day about which changes went into the product and which ones were left out. There could be a huge amount of acrimony associated with that – often times there were debates that lasted for hours as the various teams responsible for quality discussed the merits associated with a particular fix.
All-in-all, this wasn’t too different from the way that features have been developed at Microsoft for decades (and is basically consistent with what I was taught back in my software engineering class back in college).
For Windows 7, management decided to alter the engineering structure of the Windows organization, especially in the WEX [Windows Experience] division where I work. Instead of being fairly hierarchical, Steven has 3 direct reports, each representing a particular discipline: Development, Test and Program Management. Under each of the discipline leads, there are 6 development/test/program management managers, one for each of the major groups in WEX. Those 2nd level managers in turn have a half a dozen or so leads, each one with between 5 and 15 direct reports. This reporting structure has been somewhat controversial, but so far IMHO it’s been remarkably successful.
The other major change is the introduction of the concept of a “triad”. A “triad” is a collection of representatives from each of the disciplines – Dev, Test and PM. Essentially all work is now organized by triads. If there’s ever a need for a group to concentrate on a particular area, a triad is spun off to manage that process. That means that all three disciplines provide input into the process. Every level of management is represented by a triad – there’s a triad at the top of each of the major groups in WEX, each of the second level leads forms a triad, etc. So in my group (Devices and Media) there’s a triad at the top (known as DKCW for the initials of the various managers). Within the sound team (where I work), there’s another triad (known as SNN for the initials of the various leads). There are also triads for security, performance, appcompat, etc.
Similar to Windows Vista, the leads of all three disciplines get together and decide a set of features that go in each release. They then created “feature crews” to implement each of the features. Typically a feature crew consists of one or two developers, a program manager and one or two testers.
This is where one of the big differences between Vista and Windows 7 occurs: In Windows 7, the feature crew is responsible for the entire feature. The crew together works on the design, the program manager(s) then writes down the functional specification, the developer(s) write the design specification and the tester(s) write the test specification. The feature crew collaborates together on the threat model and other random documents. Unlike Windows Vista where senior management continually gave “input” to the feature crew, for Windows 7, management has pretty much kept their hands off of the development process. When the feature crew decided that it was ready to start coding (and had signed off on the 3 main documents), the feature crew met with the second level triad (in my case with DKCW) to sanity check the feature – this part of the process is critical because the second level triad gets an opportunity to provide detailed feedback to the feature crew about the viability of their plans.
And then the crew finally gets to start coding. Sort-of. There are still additional reviews that need to be done before the crew can be considered “ready”. For instance, the feature’s threat model needs to be reviewed by one of the members of the security triad. There are other parts of the document that need to be reviewed by other triads as well.
A feature is not permitted to be checked into the winmain branch until it is complete. And I do mean complete: the feature has to be capable of being shipped before it hits winmain – the UI has to be finished, the feature has to be fully functional, etc. In addition, when a feature team takes a dependency on another Windows 7 feature, the feature teams for the two features MUST sign a service level agreement to ensure that each team knows about the inter-dependencies. This SLA is especially critical because it ensures that teams know about their dependants – that way when they change the design or have to cut parts of the feature, the dependent teams aren’t surprised (they may be disappointed but they’re not surprised). It also helps to ensure tighter integration between the components – because one team knows the other team, they can ensure that both teams are more closely in alignment.
Back in the Vista day, it was not uncommon for feature development to be spread over multiple milestones – stuff was checked into the tree that really didn’t work completely. During Win7, the feature crews were forced to produce coherent features that were functionally complete – we were told to operate under the assumption that each milestone was the last milestone in the product and not schedule work to be done later on. That meant that teams had to focus on ensuring that their features could actually be implemented within the milestone as opposed to pushing them out.
For the nuts and bolts, The Windows 7 development process is scheduled over several 3-month long milestones. Each milestone allowed for 6 weeks of development and 6 weeks of integration – essentially time to fine-tune the feature and ensure that most of the interoperability problems were shaken out.
Ok, that’s enough background (it’s bad when over half a post on Windows 7 is actually about Windows Vista, but a baseline needed to be established). As I said at the beginning, this post is intended to describe my experiences as a developer on Windows 7. During Windows 7, I worked on three separate feature crews. The first crew delivered two features, the second crew delivered about 8 different features all relatively minor and the third crew delivered three major features and a couple of minor features. I also worked as the development part of the WEX Devices and Media security team (which is where my series of post on Threat Modeling came from – I wrote them while I was working with the members of D&M on threat modeling). And I worked as the development part of an end-to-end scenario triad that was charged with ensuring that scenarios that the Sound team defined at the start of the Windows 7 planning process were actually delivered in a coherent and discoverable way.
In addition, because the test team was brought into the planning process very early on, the test team provided valuable input and we were able to ensure that we built features that were not only code complete but also test complete by the end of the milestone (something that didn’t always happen in Vista). And it ensured that the features we built were actually testable (it sounds stupid I know, but you’d be surprised at how hard it can be to test some features). As a concrete example, we realized during the planning process that some aspect of one of the features we were working on in M2 couldn’t be completed during the milestone. So before the milestone was completed, we ripped the feature out (to be more accurate, we changed the system so that the new code was no longer being built as a part of the product). During the next milestone, after the test team had finished writing their tests, we re-enabled the feature. But we remained true to the design philosophy – at the end of the milestone everything that was checked into the “main” branch was complete – it was code AND test complete, so that even if we had to ship Windows 7 without M3 there was no test work that was not complete. This is a massive change from Vista – in Vista, since the code was complete we’d have simply checked in the code and let the test team deal with the fallout. By integrating the test teams into the planning process at the beginning we were able to ensure that we never put the test organization into that bind. This in turn helped to ensure that the development process never spiraled out of control. Please note that features can and do stretch across multiple milestones. In fact one of the features on the Sound team is scheduled to be delivered across three milestones – the feature crews involved in that feature carefully scheduled the work to ensure that they would have something worth delivering whenever Windows 7 development was complete.
Each of the feature crews I’ve worked on so far has had dramatically different focuses – some of the features I worked on were focused on core audio infrastructure, some were focused almost entirely on UX (user experience) changes, and some features involved much higher level components. Because each of the milestones was separate, I was able to work on a series of dramatically different pieces of the system, something I’ve really never had a chance to do before.
In Windows 7, senior management has been extremely supportive of the various development teams that have had to make the hard decisions to scale back features that were not going to be able to make the quality bar associated with a Windows release – and there absolutely are major features that have gone all the way through planning only to discover that there was too much work associated with the feature to complete it in the time available. In Vista it would have been much harder to convince senior management to abandon features. In Win7 senior management has stood behind the feature teams when they’ve had to make the tough decisions. One of the messages that management has consistently driven home to the teams is “cutting is shipping”, and they’re right. If a feature isn’t coming together, it’s usually far better to decide NOT to deliver a particular feature then to have that feature jeopardize the ability to ship the whole system. In a typical Windows release there are thousands of features and it would be a real shame if one or two of those features ended up delaying the entire system because they really weren’t ready.
The process of building 7 has also been dramatically more transparent – even sitting at the bottom of the stack, I feel that I’ve got a good idea about how decisions are being made. And that increased transparency in turn means that as an individual contributor I’m able to make better decisions about scheduling. This transparency is actually a direct fallout of management’s decision to let the various feature teams make their own decisions – by letting the feature teams deeper inside the planning process, the teams naturally make better decisions.
Of course that transparency works both ways. Not only were teams allowed to see more about what was happening in the planning process, but because management introduced standardized reporting mechanisms across the product, the leads at every level of the hierarchy were able to track progress against plan at a level that we’ve never had before. From an individual developer’s standpoint, the overhead wasn’t too onerous – basically once a week, you were asked to update your progress against plan on each of your work items. That status was then rolled up into a series of spreadsheets and web pages that allowed each manager to track all the teams’ progress against plan. This allowed management to easily and quickly identify which teams were having issues and take appropriate action to ensure that the schedules were met (either by simplifying designs, assigning more developers, or whatever).
In general, it’s been a total blast building 7. We’ve built some truly awesome features into the operating system and we’ve managed to keep the system remarkably stable during that entire process.
When we posted the new "inbox" desktop backgrouns, the reactions showed just how personal, personalization can be. Building on that theme of personalization (pun intended), we wanted to share some of the work we did on themes in Windows 7. We’ve shared data about customization in previous releases of Windows and this post builds on that. This is also an area where we know there is very broad spectrum of desires (needs) for personalization and we definitely had to balance the engineering and design efforts. I’ve received mail from many folks wanting to personalize (tweak) nearly every pixel on the screen—from border width, to title bar transparency percentage, to height of taskbar, to color/size/location of the close button (I’ve received each of these in email more than once). At the other end are customers who are enormously happy when they can easily change the background picture and color scheme, and many do. With Windows 7 we picked a group of settings that we believe represent the most satisfying settings to broadly personalize, and would also provide the most robust platform that maintains application compatibility, and made those easy to change. In addition we wanted to make it easy to package up those settings so you could save and share them. We think of this as the start of bringing robust personalization (and customization) to a broader set of customers. Katie Frigon, a program manager on the core user experience team, authored this post.
PS: Things are "slowing" down as we have talked about in how we will get to the RTM milestone. You might have noticed the announcement we made today in Asia regarding Windows 7 release and availability. Thank you to everyone who has been using the RC and helping to reach the next milestone.
In early builds, you may have noticed that Windows 7 includes a variety of themes that change your desktop background, window color and sounds with a single click. These themes are located in the Personalization Control Panel which is easily accessed from the desktop context menu.
Personalization Control Panel
Personalization Control Panel
Desktop Context Menu
Desktop Context Menu
In the RC, you can see a number of new themes, for example the “Architecture” theme. This theme is comprised of six architectural photos which cycle on the desktop background, a complementary “Twilight” window color and the “Cityscape” sound scheme which was inspired by the sounds of an urban jazz club.
A theme is a coordinated set of Desktop Backgrounds, Window Colors and Sounds.
A theme is a coordinated set of Desktop Backgrounds, Window Colors and Sounds.
Windows provides a set of themes in box and if customers want more there is a prominent link in the Control Panel to get additional themes online. This link takes you to the Windows Online theme gallery where Microsoft provides additional content including a variety of international themes.
Personalization Control Panel: Get more theme online link
Personalization Control Panel: Get more theme online link
While our customers enjoy the content we’ve provided both in the box and online we also know that they enjoy and desire the option to customize their PC’s even more than choosing a theme. Windows 7 continues to be about your PC reflecting you and what you do, as well as putting you in control of that experience. So, if you do want to go beyond the options in the box and on the web, it is easy to create and share your own themes. Creating your own theme can be as easy as just changing your desktop background image while keeping the rest of the settings the same or you can change all the settings one-by-one.
From our Beta Customer Experience Improvement Program data we see that customers are changing and creating themes. We also see many users changing the different settings, the most popular being desktop background:
Figure 1: Break out of theme type
Figure 1: Break out of theme type
Note: Only 15% of the beta users kept the default theme. 77% of the beta users created a custom theme by changing one or more elements of the inbox themes.
Figure 2: Percentage of Beta users selecting each theme component in a session
Figure 2: Percentage of Beta users selecting each theme component in a session
Note: 35% of beta users who opened the Personalization CPL clicked on “Desktop Background”.
Now let’s look at how you can change the different settings and save a custom theme. To start, you can change any of the theme settings by starting in the Personalization Control Panel.
Personalization Control Panel: Click on the items beneath the theme gallery to change your theme settings.
Personalization Control Panel: Click on the items beneath the theme gallery to change your theme settings.
Let’s start with the desktop background control panel. This control panel has been enhanced for Windows 7 to support the pictures library and the new desktop background slideshow capabilities. If you choose the “Pictures Library”, we will show all of the pictures in that library including subfolders. All you need to do is select more than one photo to have them cycle as your desktop background slideshow. In this example, I have selected some of my favorite photos from a recent trip to Hawaii to use as my desktop background.
Desktop Background Control Panel: Windows 7 adds support for libraries and desktop background slideshows. I’ve selected the pictures I want to use in my theme.
Desktop Background Control Panel: Windows 7 adds support for libraries and desktop background slideshows. I’ve selected the pictures I want to use in my theme.
When personalizing your PC, you might want to go further than just changing your background. Changing your window color or sound scheme is simple, just click on the items beneath the themes gallery. We provide 16 window colors to choose from and the ability to pick a custom color as well. New to Windows 7, we include 14 sound schemes with the OS inspired by a variety of regional music traditions, so you have plenty to choose from. If that isn’t enough, you can include your own sounds if you want.
Window Color and Sound Control Panels: It is also easy to change your window color or pick from 14 diverse sound schemes.
Window Color and Sound Control Panels: It is also easy to change your window color or pick from 14 diverse sound schemes.
After you change the desktop background, window color or sound scheme, you will notice that we have created a new “unsaved theme” that contains your changes. Your unsaved settings will be preserved when trying other themes in the gallery so you can get back to your most recent customizations. If you are happy with your personalization settings, you can ensure that they are always available in the themes gallery by clicking “Save theme”.
Personalization Control Panel: I clicked "Save Theme" to ensure that my current personalization settings will always be available in the themes gallery.
Personalization Control Panel: I clicked "Save Theme" to ensure that my current personalization settings will always be available in the themes gallery.
After saving your personalization settings for your own use, you might want to share these settings with friends and family or bring the settings to another PC. Windows 7 allows you to share your themes by right-clicking on your current theme and selecting “Save theme for sharing”. After specifying a name and folder destination for your theme, Windows will collect all of your custom desktop background images, sounds, mouse pointers and icons into the new .themepack file format that can be applied on another computer running Windows 7.
Personalization Control Panel: When I’m ready to share my theme with Friends, Family and on the Web, I right-click on my current theme and select “Save theme for sharing”.
Personalization Control Panel: When I’m ready to share my theme with Friends, Family and on the Web, I right-click on my current theme and select “Save theme for sharing”.
Sometimes after I take a fun vacation I like to create a theme that reminds me of the trip. To do this I select the best photos from the trip to rotate as my desktop background and then pair those with a matching window color and Windows 7 sound scheme that best matches the mood of the trip. After I save as a new .themepack I can either share this file via Windows Live to friends and family or use it from another PC in my house via Homegroup.
Since all of the personalization settings are now contained in a single file, it’s easy to upload the theme to Windows Live Skydrive and post a link to the theme on a Windows Live Spaces blog. Once my friends and family upgrade to Windows 7, they will be able to download themes from trips that we went on together so they can enjoy my photos on their desktop background.
Windows Live: I can also upload my theme to my Windows Live Skydrive and add a link to the theme on my blog.
Windows Live: I can also upload my theme to my Windows Live Skydrive and add a link to the theme on my blog.
In Explorer you can create a themes Library. Then from another computer in a Homegroup you just browse to the shared location and click on the desired theme to apply those settings with a single click.
Explorer: I created a themes library on one of my PC’s and shared it with my Homegroup. From another PC in the home, I can click on any of these themes to apply them.
Explorer: I created a themes library on one of my PC’s and shared it with my Homegroup. From another PC in the home, I can click on any of these themes to apply them.
One additional way we’ve added value with Windows7 themes is by capitalizing on the growing popularity of RSS photo feeds to share photos. Enthusiasts can create a theme where the desktop background slide show points to an RSS photo feed. For example, my sister lives across the country and we only see each other about once a year. An easy way for me to keep her up to date on my family is to send her a Windows 7 theme which points to my RSS photo feed. When I upload new photos they will appear on her desktop automatically.
Because there are a few different ways to create an RSS photo feed, the process to include an RSS photo feed in a Windows 7 theme will only work if your RSS photo feed links to the high resolution photos using the “enclosures” method. The feed should only reference picture formats such as JPEG or PNG. Due to this limitation themes must be created manually when including an RSS photo feed.
So, to create one of these themes you can follow these steps:
It is ready for you to share! Send the file via email, etc. to your friends and family.
Photo sharing sites can also offer these Windows 7 RSS photo themes which provide more ways to connect their customers.
Themes in Windows 7 make it possible for you to make the PC reflect you. Beyond my example of sharing personal photos as a theme, we hope that users will find new and creative ways to use themes in Windows 7. Wedding photographers can include Windows 7 themes in the packages they deliver to their clients, Artists can create themes that showcase their creative style and businesses can create themes that promote their brand. We look forward to seeing how you are using themes to Personalize these aspects Windows 7.
PS: We've posted some additional themes you can download and use on http://windows.microsoft.com/en-US/Windows7/Personalize which is the US English link from the Themes control panel.
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:
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?
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
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.
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.
Sometimes, inconsistency with your own ideals is a good thing. Make an exception, if only to put people's fears to rest.
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
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):
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:
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.
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:
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.
Here’s a behind the scenes look at the design of the Aero Snap feature in Windows 7. We thought it would be fun to take a look at the overall design process of the feature and the tools and techniques used. This feature poses a unique design challenge in that you just use the feature without any user-interface specifically to invoke it. As with all features this is a collaboration across all of our engineering disciplines. For this post, Stephan Hoefnagels, a Senior UX designer, presents the design perspective. --Steven (P.S., keep an eye out on the Microsoft MIX conference this week!)
In Managing Windows windows and Follow-up: Managing Windows windows we talked about, and you shared, some interesting window management scenarios that we might address in Windows 7. We also touched on some data around typical configurations, as well as goals that guide our thinking in this area.
In this post we’d like to have a closer look at the Aero Snap feature that many of you have already been able to experience in our PDC builds, and of course the Beta. We’ll briefly describe the feature itself, but mostly we’d like to invite you to take a behind-the-scenes peek at our design process so far, and share our iterations, challenges and considerations.
As we explained more in depth in our previous post, our top goal for the Aero Snap feature is to provide you with an effortless way to position your windows the way you want them. We want to reduce the number of clicks and precise movements needed to perform common activities. In a general sense, we want you to be able to manage your windows with confidence and create a feeling of power and control. This is something we touched on in our post on the Windows 7 taskbar as well, and really a theme that weaves through much of our new desktop experience.
Before we look at how we address our goals in the design, a quick note. In the scenarios below you’ll notice sequences of interactions that are fully written out. Sequences like: select the window, click the caption button, and then resize the window. Looking at interactions at this level of detail makes for somewhat awkward reading. These individual steps are so small, and so frequent, that for most of us they normally barely register. Why not simply gloss over some of those details? Well, we spell out sequences of events this way to force us to be consciously aware of the amount of “overhead” that is sometimes involved to get to the task at hand. It forces us to realize what we normally might not. Also, besides providing insight in the problems, it provides us with the right level of detail to consider our solutions.
Now, let’s look at the design!
As many of you mentioned, doing a drag drop operation from one window to another is sometimes a pain. Windows tend to overlap and to get them positioned right can require a lot of fine mouse movement. Oftentimes the steps are as follows: select a window, resize it appropriately, and position it on the screen so that enough of it shows for it to be a meaningful drag or drop target. Then repeat the same actions with the other window. Similarly, comparing content in two windows requires a lot of mouse clicks, resize actions, careful arrangement, window switches, and a fair amount of mouse mileage.
With Aero Snap you can grab a window and move your mouse to the edge of the screen and the window will resize to fill half the screen. Repeat with the other window. Now with two easy motions you have a setup that makes both of these scenarios much easier to accomplish!
Put windows side-by-side with Aero Snap by moving the cursor to the edge of the screen (left to right, top to bottom)
We know our users love the maximized window state. Many love it so much that they maximize all of their windows and never even run in any other state! However, with screens increasing in resolution and widescreen layout becoming more prevalent, the maximized window state can lose some of its appeal in certain cases. E-mail is an example. Reading long lines of text across the screen is not ideal. Your eye simply cannot track a line all the way across. Web browsing is another example. Content will sometimes not fill the entire width of the screen, leaving a lot of unused white space on the side.
Now, with Aero Snap you can you can maximize a window in the vertical direction only. When you resize a window to the top of the screen, it will also resize all the way to the bottom. Great for reading long blog posts!
Vertically maximize a window with Aero Snap by resizing the window to the edge of the screen
We realize there are a few multi-mon users out there, especially amongst the readers of this blog ;-). Ever wanted an easier way to move a maximized window to another screen? A way that’s quicker than clicking the restore caption button, moving the mouse to the title bar, dragging the window over, and finally clicking the maximized caption button again? With Aero Snap you can simply drag a maximized window down, move it over and snap it to the top, all in one gesture. Finally!
Arranging windows on a desktop PC can sometimes involve excessive fiddling, fine mouse movements and lots of mouse mileage, as touched on above. On laptops this situation is further exacerbated by the lack of a mouse, making some of these movements even more cumbersome. For these scenarios, and our power users, we’ve introduced some convenient key combinations. Hold down the Windows key and one of your arrow keys to give it a try. You may want to try holding down Shift as well, especially if you’re in a multi-mon setup.
OK - So those are the scenarios, and the way we chose to address them. Seems straightforward enough, right? Especially for those of you that have been using Aero Snap in out Beta build. It all behaves as you’d expect. But how did we get here? Well, in this next bit we’d like to something that we don’t do that often and really give you a peek into our design process so far and some of the snags we ran into along the way. Keep in mind that this is a brief overview and by no means exhaustive. While we allude to usability testing for instance, this post is by no means meant to give insight into the scope of those efforts. There will certainly be opportunities to talk about some of those topics in the future.
Let’s have a look!
We’re back in early 2007, and after we established window management as a potential area of interest, and identified several appealing scenarios (again, see our previous post for more detail on that stage of the process), we started with brainstorms to generate ideas. “How can we make window arranging more efficient?” “More direct?” “More fun?” are some of the questions we asked ourselves. This was a multidisciplinary process, with disciplines like design, user research, program management and development involved. All in all there were around a handful of us, certainly less than a dozen, thinking about this space at the time.
We imposed a significant constraint on ourselves: we wanted to achieve our goals without introducing any extra widgets in our UI. Imagine an extra caption button on the window title bar for instance: this may not seem too bad for one window, but when we’re talking about 10 windows or more, we’ve all of a sudden introduced a significant amount of clutter on your screen. And that’s something that we simply didn’t feel good about. After all, as we shared in our UX Principles talk at the PDC, we believe in “Solving Distractions, not Discoverability”.
We captured our, many, ideas in very quick sketches that we shared via an internal website. Transferred from the whiteboards in our offices and hallways, these took less than 5 minutes to sketch each. The sketches below are some actual examples in which you can start some of the Aero Snap ideas forming.
Early ideas are captured in quick and disposable sketches
With so many ideas on paper we were eager to try out the best ones. Now was the time to prototype. Note that we are still very early in the process. We wanted our prototypes to be interactive, and we wanted to be able to live with them in our day-to-day work. So we chose to implement the ideas using early code that we could run on our work machines. For example, the image below shows a “smart resizer” prototype running on Windows Vista. Of course these prototypes are not “done” features that we could actually ship: they merely get the basic ideas working, and they definitely have more than a few “quirks” (bugs ;-)). What’s important however, is that they allow us to experience just enough of the interactions ourselves, as well as get feedback in usability studies.
Early “smart resizer” prototype running on Windows Vista, note the taskbar button created by the prototype (and the date in the calendar to get a sense of where we are in the process)
We use this firsthand experience and early usability feedback to iterate on the ideas as we hone in on the final design. We approach this part of the process in a very open minded way and allow ourselves to be surprised. Sometimes ideas that don’t look like much on paper prove to be startlingly powerful. On the other hand, we found out that others look much better on paper than they were in practice! Since we’re not invested in any one idea or implementation yet, we freely refine, and drop ideas.
Finally, the prototypes ease us into thinking about design details. And we might stumble on some insights too (of course we tell ourselves the real feat is to recognize the insight and hold on to it). Here’s an example from an e-mail at the time from one of the team members about a new version of the “smart resizer” prototype:
I noticed something changed. In the original version if I resized it to the max it “supersized” the window. Then if I resized the window smaller, it jumped back to the normal restored state. It was as if the supersize state was different than restored state. With this version when I supersize the window and then resize it again later, it doesn’t jump back to the previous restored size. There was something kind of nice about the supersized state being different than the restored state. We should think about it more and consider making that a part of the design.
I noticed something changed. In the original version if I resized it to the max it “supersized” the window. Then if I resized the window smaller, it jumped back to the normal restored state. It was as if the supersize state was different than restored state. With this version when I supersize the window and then resize it again later, it doesn’t jump back to the previous restored size. There was something kind of nice about the supersized state being different than the restored state. We should think about it more and consider making that a part of the design.
After many a prototype we settled on the concept of side-by-side windows and vertical maximized windows. We’re getting clearer on what we want to build.
OK - We’ve whittled down our ideas to a good, but not fully specced, set of interactions and behaviors. Time to start filling in the blanks by asking detailed questions. “What does it mean to have a side-by-side window in a world where there used to be only minimized, restored and maximized windows?” “How exactly would you get to and from this new window state?” The e-mail snippet above already pointed to some of these questions.
Currently the common window states are (left to right) minimized, restored, and maximized, how would side-by-side and vertical maximized windows fit in?
Let’s look at the state problem in detail. Below is an example of two proposals made during this time that show how you can move from one window state to another, for all the different states. Which model is better?
Two proposals detailing the various ways we can transition between states
To answer that question we considered more specific questions like “What states do we want to link directly and how do we move between them?” “Is it compelling to go from a vertical maximized state directly to a maximized state?” “Should the vertical maximized and side-by-side states behave similar, as they look similar?” Our answers of course guided us to the model that you are now familiar with, which is model B.
But that’s not the end of it. More details need to be worked through, and more questions come up. “What if I want to move a vertical maximized window sideways?” “Resize its width?” “Then pull it down?”
Soon you’ll find yourself in elaborate sequences of events, many possible actions, and even more possible outcomes. Which would be the most expected when actually using the entire system?
To help guide our decision making process we established some guiding statements. Assumptions that we hold to be true. Examples are: “The intuitive way to undo an effect triggered by a mouse movement is to make the opposite mouse movement.” And: “It should always be effortless to go back to the previous “restored” state so as to avoid excessive work to get the window back to a reasonable size.” Or: “If the user specifies a width for a window in a given state, that size should be preserved across state changes when it makes sense.”
Using these statements we were able to answer questions like the ones above in a predictable way and as a result craft a predictable experience. And while the underlying state transitions and rules are fairly complex when added all together, the resulting behavior is, we hope, intuitively understood. That’s definitely something we’re aiming for.
Here’s an example of a sequence problem for the really attentive reader. When working through our many new state transitions, sometimes the rules that determine what should happen, conflict. Consider the following scenario. Two rules in our new window model are:
OK – Let’s try the following scenario in your Windows 7 build. Start with a restored window. Vertically maximize it by resizing it to the top of the screen. Release the mouse. Drag (don’t resize) down the window and drag it to the top again, all in one motion. Release the mouse. What happened?
Your window should be maximized. Which means in this case we chose to follow rule 1. We could have also followed rule 2, in which case your window would be vertically maximized. We figured rule 1 would more accurately reflect the user’s mental model for this scenario.
This is just one example of the decisions we had to make for each transition to and from a window state.
Throughout this process we made sure to preserve the subtleties in the current model. One small example that some of you may be familiar with that we did tweak is the scenario of dragging a window title bar off screen. In previous Windows releases we would snap the window back halfway in an attempt to provide you with just enough space to still move the window around, while optimizing vertical space as much as possible. We chose to be a little more deliberate and straightforward here by snapping back so that the entire title bar is visible. This way you can start to rely on the fact that all of your windows are always very easy to grab, also with touch, and move around. If we really felt half of a title bar is enough, why don’t we always half it, right? For our vertical maximized window states we of course chose to keep the entire title bar visible as well, leading to a solid story all around.
State diagrams are of course only one way to look at the world. We used various ways to communicate different aspects of the feature, picking our medium based on familiarity, availability and intent. We didn’t even shy away from the occasional ASCII art as you can see below! We’ll simply use whatever tool gets the point across. Most of all, interaction storyboards were a very valuable technique to help us understand the user flows, and even though this is only a small sample, you can see we did quite a few of those.
Feature details are communicated throughout using appropriate means
Besides figuring out the right state transitions, one or our biggest discussions was around when a state transition should exactly occur, or in other words: when the feature is triggered. We talked a lot about “accidental triggers”, i.e. running into the feature without deliberately setting out to do so.
Aero Snap is triggered by touching the edge of the screen with the mouse
From the very beginning we always made sure that our feature did not get in the way of current scenarios such as tucking a window off-screen to the side. After all, we don’t want to have a detrimental effect on your current, expected, way of managing your windows. That’s why you have to literally touch the edge of the screen with your mouse, not the window edge, to trigger the transitions.
However, at this time, the feature as you know it now was different in one very important, fundamental way. In our early builds, Aero Snap followed an “instant commit” model. When you moved your mouse to the top of the screen, your window would literally be maximized while you’re still dragging. That is, before you even release the mouse. Moving back in one motion would literally restore the window. We liked this approach as the “preview” was very accurate, i.e. the preview was the window, and there is a certain directness in not having a commit model.
Because our UI is invisible by design, we expected some accidental triggering. In fact in some sense we were relying on accidental triggers to help with the discoverability of the feature. However, after living with the builds for a while we got a little worried because accidental triggering seemed higher than we expected. From our telemetry data we saw people running into the feature, and then cancelling it nearly twice as often as committing. In our usability studies we observed confusion as to what exactly triggered the behavior. Was it the window touching the edge that did this? A gesture? Or something else?
We’re now in early 2008. What should we do? Cut the entire feature? We actually did consider this as an option. Again, we really respect our current window management behaviors, and the last thing we wanted to do is degrade the experience. More constructively, we took on the challenge to come up with a design tweak that would address these issues. We explored several solutions. Some conservatively centered on smoothing out the resize transitions, so an accidental trigger would at least be smooth. A conservative approach for sure, but probably not satisfying enough as a real solution. Others focused on trying to detect user intent more accurately, based on the angle of motion into the screen edge, or the speed of the motion. This proved much too complex to be predictable. Maybe we could trigger the transition only when double-bumping the edge? We were worried that this would degrade the experience of fluidity and flow of the current model.
In the end we settled on the implementation you’re familiar with. We don’t trigger until you release the mouse, making it easy to back out of the effect before anything happens to your window. In addition we provide you with a smooth preview animation, and a cursor effect to help you understand what just happened. This way you can be more deliberate in the future, and use the feature to your full advantage.
Did we solve the issues? Feel free to let us know :-)
It’s interesting to think back and realize that up to this point we had essentially designed a feature without any visible UI whatsoever. Now all of a sudden we have window previews, and a cursor effect. What should those look like, and how should they behave?
Well, luckily we had some things to go on. At this point we had already established a clear picture of our taskbar look and feel (we call it “personality” and will talk about it more in a later post). We had settled on using glass sheets for Aero Peek. We saw an opportunity to use the same visual representation for our preview windows. But how should the glass sheets appear? After experimentation, we settled on a scale animation that originates from the cursor. This gives a subtle hint as to where this preview window came from. We also made sure to animate our transitions. Try this in your build for instance: move a window to the top, and then to the side, in one motion without releasing the mouse. Notice the smooth morph of the preview? Why did we spend time on this? We believe “Small Things Matter, Good and Bad” of course.
Light effects are used to indicate the snap trigger, and glass sheets for snap previews
Finally, we tied into some of our ideas around “light” for the trigger indication. We tuned this to be noticeable, but not too loud and made sure to synch with other light effects in the system such as our touch feedback.
We hope this post has given you some insight in the Aero Snap feature, including our design process. We would love to hear your thoughts!
Back in January we released the Beta and updated you on our overall engineering process that will get us from Beta to the Release Candidate. Today, downloading of the Release Candidate started and we’re already seeing a lot of installations and a lot of excitement. On behalf of the team, I want to extend a thank you for all of the millions of people who have been running and testing the Beta who have helped to make the Release Candidate possible. The feedback we have received, through all the mechanisms we have blogged about, has been an incredibly valuable part of Engineering Windows 7. We continue to be humbled by the response to Windows 7. Thank you!
This post is about the path from RC to what we call RTM, release to manufacturing. RTM is not one point in time but a “process” as from RTM we enable the PC manufacturers to begin their processes of building Windows 7 images for new PCs, readying downloads for existing machines, and preparing the full supply chain to deliver Windows 7 to customers. Thus RTM is the final stage in our engineering of Windows 7, but the engineering continues from RTM until you can purchase Windows 7 and Windows 7 PCs in stores at General Availability, or GA.
The path to RTM starts with downloads of the RC. The RC is “done” and what we are doing is validating this against the breadth of the ecosystem and with partners. It means, from our perspective, we have run many tests many times and are working to understand the quality of the release in a breadth sense. We’re all familiar with this as we have done this same thing as we went from pre-Beta to Beta and from Beta to RC. The primary difference with the RC is that we will not be changing the functionality or features of the product at this point—that’s the sort of thing we’ll save for a future release. We’ve gotten tons of feedback on design and features and shown how we have digested and acted on this feedback throughout many posts on this blog. We know we did not do everything that was asked, and we have also seen that we’ve been asked to do things that are tricky to reconcile. We hoped through the dialog on this blog that we’ve shown our commitment to listening and balancing a wide variety of inputs, and how we have thought about the evolution of Windows.
What sort of feedback are we looking for in the RC? We are primarily focused on monitoring the behavior of the product through the telemetry, and of course making sure we did not introduce any regressions in any dimension from Beta quality. One of the things we have done since Beta has continued to beef up telemetry—we’ve put in additional monitoring points in many systems. We’re particularly interested in seeing what devices are installed, drivers that are required, and overall system performance. We have telemetry points that monitor the UI responsiveness of the Start Menu, Internet Explorer (recently posted), Boot, Shutdown, Resume, and across all subsystems. Of course in the final product, this telemetry is optional and opt-in, and it is always private.
There are a series of specific types of reports that we are keeping an eye out for that would constitute changes we would make to the code between now and RTM. Some of these might include:
All of the feedback will be evaluated and whether the issue is with Windows itself or with hardware, software, or OEM partner code we will work closely across the entire ecosystem to do what is necessary to deliver excellent fully integrated PCs. This goal is more important than anything else at this point. The depth of this work is new for the team in terms of spending engineer to engineer time across a broad range of partners to make sure everyone is ready together to deliver a great PC experience.
Overall, while many have said that the quality of the Beta was on par with past RCs (remember how some even suggested we release it as final!), we are working to do an even better job with Windows 7. We think we have the tools in place to do that.
While the RC itself was compiled about 2 weeks ago, it takes a bit of time to go through the mechanics of validating all the ISOs and images that are released. In the meantime we continue doing daily builds of the product. The daily builds are incorporating code changes to address the above types of issues that impact enough customers that on balance the code change is more valuable than the potential of a regression. Throughout this process, every change to the code is looked at by many people across development and test, and across many different teams. We have a lot of engineers changing a very little bit of code. We often say that shipping a major product means “slowing everything down”. Right now we’re being very deliberate with every change we make.
The RTM milestone is not a date, but a process. As that process concludes, we are done changing the code and are officially “servicing” Windows 7. That means any subsequent changes are delivered as fixes (KB articles) or banked for the first service pack. Obviously our ability to deliver fixes via Windows Update has substantially changed the way we RTM and so it is not unreasonable to expect updates soon after the product is complete as we have done for both Windows XP and Windows Vista.
Between now and the RTM milestone we will make changes to the code in response the above inputs. We are decelerating and will do so “gracefully” and not abruptly. We do not have a “deadline” we are aiming to meet and the quality (in all dimensions) of the product and a smooth finish are the most important criteria for Windows 7. In addition, we have a lot of work going on behind the scenes to build Windows 7 in nearly 100 languages around the world and to make sure all the supporting materials such as our Windows web site, SDK, resource kits, and so on are ready and available in a timely manner.
Once we have entered the RTM phase, our partners will begin to make their final images and manufacture PCs, and hardware and software vendors will ready their Windows 7 support and new products. We will also begin to manufacture retail boxes for shipment around the world. We will continue to work with our enterprise customers as well and based on the RTM process the volume license products will be available as well.
Delivering the highest quality Windows 7 is the most important criteria for us at this point—quality in every dimension. The RTM process is designed to be deliberate and maintain the overall engineering integrity of the system. Many are pushing us to release the product sooner rather than later, but our focus remains on a high quality release.
Ultimately our partners will determine when their PCs are available in market. If the feedback and telemetry on Windows 7 match our expectations then we will enter the final phases of the RTM process in about 3 months. If we are successful in that, then we tracking to our shared goal of having PCs with Windows 7 available this Holiday season.
--Steven and Jon
Larry is very appreciative of the reception and comments his post received. Thank you! It is worth noting that we’ve surpassed over 2000 comments and I’ve received and equal amount of email. I am trying to reply as often as I can!
We’re 10 days from the PDC and so we might take a short break from the blog while we practice our demos of Windows 7…we’ll keep an eye on comments for sure and maybe a post or two on the way. :-)
Let's move "up" in the dev process and look at how we come up with what is in a release and how we think about taking a feature from an idea to feature.
As we’ve posted on various engineering challenges we’ve often distilled the discussion down to a few decisions, often between two options (make a feature optional or not, add a window management feature one of two ways, etc.) Yet this doesn’t quite get to the challenge of where does the product definition begin and how do we take an idea and turn it into a feature. Most choices in engineering Windows are not between two choices, but the myriad of considerations, variables, and possibilities we have before we even get to just a couple of options. This post looks a bit at the path from an idea to a feature.
A common thread we’ve seen in the feedback is to make “everything customizable and everything optional” (not a direct quote of course). Of course, by virtue of providing a platform we aim to offer the utmost in extensibility and customization by writing to the APIs we provide. There is an engineering reality that customization and extensibility have their cost—performance, complexity, and forward compatibility come to mind. One way to consider this is that if a feature has two “modes” (often enable the new feature or enable the old feature) in one release, then in a follow-up release if the feature is changed it potentially has four modes (old+old, old+new, new+old, new+new), and then down the road 8 modes, and so on. The complexity of providing a stable and consistent platform comes with the cost that we aren’t always able to “hook” everything and do have to make practical choices about how a feature should work, in an effort to plan for the future. Designing a feature is also about making choices, tough choices. At the same time we also want to provide a great experience at the core operating system functions of launching programs, managing windows, working with files, and using a variety of peripherals--to name just a few things Windows does. This experience should be one that meets the needs of the broadest set of people across different skill levels and different uses of PCs, and also providing mechanisms to personalize with user interface and to customize with code. Every release we plan is a blending of fixing things that just don’t work like we all had hoped and developing new solutions to both old and new problems, a blending of features and extensibility, and a blending of better support for existing hardware and support for new hardware.
This post is jointly written by Samuel Moreau the manager of the user experience design team for the Windows Experience, Brad Weed, Director of User Experience Design and Research for Windows and Windows Live, and Julie Larson-Green, the VP of Program Management for the Windows Experience. With the number of comments that describe a specific feature idea, we thought it would be good to give you an overview of how we approach the overall design process and how ideas such as the ones you mention flow into our process. Also for those of you attending the PDC, Sam will be leading a session on the design principles of Windows 7. –Steven
In general, we follow a reasonably well-understood approach to product design, but that doesn’t make it easy or “automatic”. Often this is referred to as a "design funnel" where ideas go from concept to prototype to implementation and then refinement. By reading the various design ideas in the comments of Chaitanya’s post on “Starting, Launching and Switching”, you can see how difficult it can be to arrive at a refined feature design. In those comments you can find equally valid, yet somewhat opposite points of view. Additionally, you can also find comments that I would paraphrase as saying “do it all”. It is the design process that allows us to work through the problem to get from idea to feature in the context of an overall product that is Windows.
From a product design perspective, the challenge of building Windows is the breadth of unique usage of just a single product. In a sense, one of the magic elements of software is that it is “soft” and so you can provide all the functionality to all customers with little incremental cost and little difference in “raw materials” (many comments have consistently suggested we have everything available along with options to choose components in use and we have talked about minimizing the cost when components and features are not used even if they are available). And at the same time, there is a broad benefit to developers when they can know a priori that a given PC has a common set of functions and can take advantage of specific APIs that are known to be there and known to behave a specific way--the platform. This benefit of course accrues to individuals too as you can walk up to any PC and not only have a familiar user experience, but if you want to do your own work, use a specific device, or run a certain program on the PC you can also do that. This breadth of functionality is a key part of the value of a Windows PC. Yet it also poses a pretty good design challenge. Learning, understanding, and acting on the broad set of inputs into designing Windows is an incredibly fun and challenging part of building Windows.
As Larry pointed out the design and feature selection happens takes place in his part of the organization (not way up here!). There’s another discussion we will have in a future post about arriving at the themes of the overall release and how we develop the overall approach to a release so that the features fit together and form a coherent whole and we address customer needs in an end-to-end fashion.
We have a group of product designers that are responsible for the overall interaction design of Windows, the sequence and visualization of Windows. Program Managers across the team work with product designers as they write the specifications. Along with designers we have UX Researchers who own the testing and validation of the designs as we’ve talked about before. The key thing is that we apply a full range of skills to develop a feature while making sure that ownership is clear and end-to-end design is clear. The one thing we are not is a product where there is “one person” in charge of everything. Some might find that to be a source of potential problems and others might say that a product that serves so many people with such a breadth of features could not be represented by a single point of view (whether that is development, testing, design, marketing, etc.). We work to make sure engineers are in charge of engineering, that the product has a clear definition that we are all working towards implementing and that product definition represents the goals across all the disciplines it takes to deliver Windows to customers around the world. And most importantly, with Windows 7 we are making renewed effort at "end to end" design.
Let’s look at the major phases of product design in Engineering Windows. What we’ll talk about is of course generalized and doesn’t apply to each specific incident. One thing we always say internally is that we’re a learning organization—so no process is perfect or done and we are always looking to make it better as we move through each and every iteration of building Windows.
Throughout this post when we say “we” what this really means is the individuals of each discipline (dev, test, pm, design) working together—there’s no big feature or design committee.
We get an idea from somewhere of something to do—it could be big (build UX to support a new input method such as touch), wild (change the entire UI paradigm to use 3D), or an improvement / refinement of an existing feature (multi-monitor support), as some examples. There is no shortage of creative ideas, because frankly, that is the easy part. Ideas flow in from all corners of the ecosystem, ourselves included. We’ve talked a lot about comments and feedback from this blog and that is certainly one form of input. Product reviews, enterprise customers, customer support lines, PC makers, hardware and software developers, blogs, newsgroups, MVPs, and many others have similar input streams into the team.
The key is that working on Windows is really a constant stream of inputs. We start with a framework for the release that says what goals and scenarios we wish to make easier, better, faster. And with that program management builds up candidate ideas—that is ideas that will make their way through features. The job of getting a feature “baked” enough falls to program management and they do this work by working across the product and working with design, development, and testing (as Larry described).
With regard to where ideas come from, what we like to say is that the job of program management is not to have all the great ideas but to make sure all the great ideas are ultimately picked. The best program managers make sure the best ideas get done, no matter where they come from.
Given any idea, the first step is to understand what data we have “surrounding” the idea. Sometimes the idea itself comes to us in a data-centric manner (customer support incidents) or other times it is anecdotal (a blog).
The first place we look is to see what data do we have based on real world usage that would support the development of a hypothesis, refute or support the conventional wisdom, or just shed some light on the problem. The point is that the feature starts its journey by adding more perspectives to the input.
Essentially, we need an objective view that illuminates the hypothesis. We gather this data from multiple sources including end users, customers, partners, and in various forms such as instrumentation, research, usability studies, competitive products, direct customer feedback, and product support.
As many (including us) have pointed out, telemetry data has limitations. First, it can never tell you what a person might have been trying to do—it only tells you what they did. Through usability, research, and observation, we are able to get more at the intent. For example, the way we talked about high dpi and how the telemetry showed one thing but the intent was different (and the impact of those choices was unintended). The best way to see this is to remember that a person using a PC is not interesting in “learning to use a PC” but is trying to get their own work done (or their own playtime). And when faced with a “problem” the only solutions available are the buttons and menu commands right there—the full solution set is the existing software. Our job is to get to the root of the problem and then either expand the solution set or just make the problem go away altogether.
What about unarticulated needs? The data plus intent shows the “known world” and “known solution space”, but one role we have is to be forward thinking and consider needs or desires that are not clearly articulated by those who do not have the full time job to consider all the potential solution spaces. The solution space could potentially be much broader than readily apparent from the existing and running product—it might involve a rearchitecture, new hardware, or an invention of a new user interface.
A great example of this was mentioned in one of the comments on the taskbar post. The comment (paraphrasing) indicated that the order of icons on the taskbar matters so sometimes he/she would simply close all the open programs and then restart them just so the programs were in the preferred order on the taskbar. Here the data would look like an odd sequence of launch/exit/launch/exit/launch/lauch. And only through other means would we learn why someone would be doing that, and for the most part if you just walked up without any context and said “how can we make Windows easier” it isn’t likely this would bubble up to the top of the list of “requests”. Thus we see a number of neat things in this one example—we see how the data would not show the intent, the “request” would not be at the top of any list, and the solution might take any number of forms, and yet if solved correctly could be a pretty useful feature. Above all, in hindsight this is one of those “problems” that seems extraordinarily obvious to solve (and I am sure many of you are saying—“you should have just asked me!”) So we also learn the lesson that no matter what data and information we gather or what design we’re talking about, someone always noticed or suggested it :-).
The next step is where we propose a clear hypothesis – “people would benefit from rearranging icons on the taskbar because positional memory across different sessions will reduce the time to switch applications and provide a stronger sense of control and mastery of Windows”.
What is our hypothesis (in a scientific sort of way) as to what opportunity exists or what problem we would solve, and what the solution would look like, or why does the problem exist? Part of designing the feature is to think through the problem—why does it exist—and then propose the benefit that would come from solving the problem. It is important that we have a view of the benefit in the context of the proposed solution. It is always easy to motivate a change because it feels better or because something is broken so a new thing has to be better, but it is very important that we have a strong motivation for why something will benefit customers.
Another key part about the hypothesis is to understand the conventional wisdom around this area, especially as it relates to the target customer segment (end-user, enthusiast, PC maker, etc.) The conventional wisdom covers both the understanding of how/why a feature is a specific way today and also if there is a community view of how something should be solved. There are many historic examples where the conventional wisdom was very strong and that was something that had to be considered in the design or something that had to be considered knowing the design was not going to take this into account—a famous example is the role of keyboard shortcuts in menus that the “DOS” world felt would be required (because not every PC had a mouse) but on the Mac were “unnecessary” because there was always a mouse. Conventional wisdom in the DOS world was that a mouse was optional.
For any hypothesis, there are numerous design alternatives. It is at this stage where we cast a broad net to explore various options. We sketch, write scenarios, story board, do wireframes and generate prototypes in varying fidelity. Along the way we are working to identify not just the “best answer” but to tease out the heart and soul of the problem and use the divergent perspectives to feed into the next step of validation.
This is a really fun part of the design process. If you walk our hallways you might see all sorts of alternatives in posters on the walls, or you might catch a program manager or designer with a variety of functional prototypes (PowerPoint is a great UI design tool for scenarios and click-thrus that balance time to create with fidelity, and Visio is pretty cool for this as well) or our designers often mock up very realistic prototypes we can thoroughly test in the lab.
With a pile of options in front of us we then take the next step of interpreting our own opinions, usability test data and external (to the team) feedback. This is the area where we end up in conversations that, as an example, could go something like this… “Option ‘A’ is better at elevating the discovery of a new feature, but option ‘B’ has a stronger sense of integration into the overall user experience”.
As we all know, at the micro level you can often find a perfect solution to a specific problem. But when you consider the macro level you start to see the pros and cons of any given solution. It is why we have to be very careful not to fall into the trap of a “tests”. The trap here is that it is not often possible to test a feature within the full context of usage, but only within the context of a specific set of scenarios. You can’t test how a feature relates to all potential scenarios or usages while also getting rich feedback on intent. This is why designing tests and interpreting the results is such a key part of the overall UX effort led by our researchers.
A mathematic way of looking at this is the “local min” versus a “global min”. A local min is one you find if you happen to start optimizing at the wrong spot on the curve. A good example of this in software is when faced with a usability challenge you develop a new control or new UI widget. It seems perfectly rational and often will test very well, especially if the task asked of the subject is to wiggle the widget appropriately. However, what we’re after is a global optimization where one can see that the potential costs (in code, quality, and usability) of another widget by erase any potential benefits gained by introducing a new widget. Much has been written about the role of decision theory as it relates to choosing between options, but our challenge with design is the preponderance of qualitative elements.
Ultimately we must pick a design and that choice is informed by the full spectrum of data, qualitative and quantitative.
Given a choice for a design and an understanding of how to implement it and the cost, there is still one more choice—should we do the feature at all. It sounds strange that we would go through all this work and then still maybe not build a specific feature. But like a movie director that shoots a scene that ends up on the cutting room floor, sometimes the design didn’t pan out as we had hoped, sometimes we were not able to develop an implementation plan within reason, or sometimes there were other ideas that just seemed better. And this is all before we get to the implementation, which as Larry pointed out has challenges as well.
We have two tools we use to assist us in prioritizing features and designs. First is the product plan—the plan says at a high level what we “require” the product to achieve in terms of scenarios, business goals, schedule, and so on. Most of the time features don’t make it all the way through prototyping and testing because they just aren’t going to be consistent with the overall goals of the release. These goals are important otherwise a product doesn’t “hang together” and runs the risk of feeling like a “bunch of features”. These high level goals inform us quite a bit in terms of what code we touch and what scenarios we consider for a release.
And second we have the “principles of design” for the release. These principles represent the language or vocabulary we use. These represent the core values—we often think of the design principles as anthropomorphizing the product—“if Windows were a person then it would be…”. This is the topic of Sam’s talk at the PDC.
As mentioned in the introduction, it isn’t possible to do everything twice. We do have to decide. This could be a whole series of posts—customization, compatibility modes, and so on. We definitely hear folks on these topics and always do tons of work to enable both “tweaking” and “staying put” and at the same time we need to balance these goals with the goals of providing a robust and performant platform and also moving the OS forward. Some of us were involved in Office 2007 and there is a fun case study done by Harvard Business School [note fee associated with retrieving the full text] about the decision to (or not to) provide a “compatibility mode” for Office 2007. This was a choice that was difficult at the time and a few folks have even mentioned it in some comments.
Finally, we build and iterate to refine the chosen solution. Inevitably there are new discoveries in the implementation phase and we adjust accordingly. As we integrate the solution into its place in Windows, that discovery continues. The beta period is a good example of how we continue to expand and learn from usage and feedback. In a Windows beta we are particularly interested in compatibility and real-world performance as those are two aspects of the design that are difficult to validate without the breadth of usage we can get if we do a great beta.
It is important to keep in mind that we follow intensely all the feedback we receive from all forms—reviews, blogs, and of course all the telemetry about how the product is used (realizing that the beta is a select group of people).
One of the things we hope to do with the blog, as you might have seen on the IE 8 Blog, is to discuss the evolution of the product in real-time. We’re getting close to this transition and are looking forward to talking more about the design choices we made!
-- Sam, Brad, and Julie
Delivering excellent audio playback on a PC is one of those “much harder than it looks” technical challenges. Unlike dedicated audio / video devices, PCs have a lot going on during playback of audio and the playback happens on an incredible array of hardware and software. Many of you might be familiar with “glitches” that occasionally happen. In this post, Kristin Carr, a program manager on our Devices and Media team, describes some of the engineering in Windows 7 to improve this area representing the work of a number of folks across the team. One lesson I learned early in the product cycle is that we don’t say “glitch-free” but rather “glitch-resilient” and hopefully that will make sense as you read this. --Steven
Have you ever used your PC to play an MP3 or a DVD? If you answered yes, you’re among the overwhelming majority of PC customers who use their computer for audio and video applications, encompassing everything from watching a movie to playing a game to viewing a YouTube clip. But you may have also had an experience where your audio or video wasn’t quite perfect – perhaps the video was a bit choppy or the audio stuttered. We call this a ‘glitch’ – a perceived discontinuity in your audio or video that interrupts the playback experience. In this blog post, we’ll be focusing on audio glitching: we’ll examine the ecosystem challenges that can cause glitches, and we’ll discuss the work we’ve been doing to improve the Windows 7 experience.
In previous posts, we’ve touched on a variety of ecosystem initiatives and challenges that we’ve undertaken for Windows 7, including application compatibility, accessibility, and system performance, among others. Tracing the root cause of audio glitching leads us to a similar place: because Windows runs on a huge variety of hardware configurations and multitasks between dozens of applications, it is challenging to ensure that all of the programs and drivers running on your computer will work together in exactly the way you expect.
Audio is especially sensitive. In order for you to hear music from your speakers, data needs to be delivered to your audio hardware approximately every 10 milliseconds, or 30 times in the blink of an eye! The challenge is that your PC is usually doing a lot of other things at the same time you’re listening to music, such as streaming that YouTube video or downloading that new song, and many of these other tasks have complex timing requirements as well. As you can imagine, it doesn’t take much – a slow network driver or a graphics driver that requires plenty of CPU time – to prevent your audio from reaching your ears in a continuous fashion.
So what are we doing to address this challenge? The answer is ‘lots!’ – and the remainder of this blog post will be devoted to discussing these things:
Who Experiences Glitching?
In studying this during the Windows 7 development cycle, our first order of business was to gather data. We‘d heard reports of audio glitching, but we didn’t know the exact scope of the problem. How often do users hear their audio glitching? Are there certain machines that were worse than others? With these questions in mind, we set out to understand our problem space a bit better.
We gathered data by using the telemetry infrastructure built into Windows, which allows our users to report back to Microsoft with performance data and other statistics that help us improve the OS. For each machine that opted to contribute data to Microsoft, we measured the number of times that the underlying audio hardware was being starved for data (i.e., when the user might hear a glitch). This data was grouped into “sessions,” each of which represents the data collected on a single machine for a single day or the data collected between machine reboots, whichever is shorter.
Let’s dive into some of the results. First, let’s look at the overall rate of audio glitching:
Figure 1: Distribution of Glitch Counts per Session
The chart above shows data from external (non-Microsoft) RC users. Approximately 80% of sessions showed no glitching at all, but 4.3% showed 10 or more glitches, which indicates that audio glitching affects a significant number of users.
Once we figured out how often glitching occurs, we started looking into why it occurs. First, we broke the data down by laptop/desktop form factor:
Figure 2: Glitching Likelihood by Form Factor
From this data, we noticed that laptops were almost twice as likely to experience audio glitching. As a result, we’ve made sure to address and target mobile PCs as well as mobile scenarios (for example, playing music while running on battery) for better coverage in our glitching tests and diagnostic tools.
Next, we looked at glitching likelihood by PC manufacturer:
Figure 3: Glitching Likelihood by PC Manufacturer (Mfr)
This data showed that certain manufacturers were more likely to be susceptible to audio glitching than others. As a result, we made sure to spread our testing efforts across a wide spectrum of machines and manufacturers. In addition, we are using this data to work with manufacturers to see if we can identify components or specific causes that would result in higher glitch incidents.
Finally, we looked at glitching on a wide variety of PC models:
Figure 4: Breakdown of All Glitch Sessions by PC Model
In the chart above, we examined all of the sessions that had at least one glitch, and we looked for any correlation with the PC make and model as shown in the table above (actual machine names have been anonymized). The first thing to notice is that Machine A is responsible for more than three times as much audio glitching as any of the other machines on the list. This data confirmed earlier reports of audio glitching on this particular machine, which we traced to a graphics card that shipped in a faulty configuration. As a result, we were able to work with the manufacturer to improve the configuration.
This chart also helps to show how widespread the issue is. There were hundreds of PC models that showed evidence of glitching – in fact, it seemed difficult to find a single PC model for which audio glitching did not ever occur. On the other hand, most individual machines didn’t show any problems at all. The conclusion that we drew was that audio glitching was not caused by any one hardware configuration, but was dependent on all the different hardware and driver permutations a user could possibly encounter on their machine. It was clear that no machine was immune, and in order to improve the experience, we were going to need a far-reaching, system-wide solution to this problem.
Once we had data on when and why glitching occurs, the Windows Devices & Media Performance team developed a comprehensive suite of tests that were centered around media playback scenarios and were designed to assess how well a PC performed at that scenario. During media playback, these tests recorded thousands of statistics about the system’s performance, including CPU load, the activity of all components on the system and their corresponding interactions, and whether glitching occurred, among other things. We intentionally covered a huge range of scenarios and configurations, including laptops running on battery power, hardware under stress, hundreds of media content types, and many more. The goal was to exercise each PC in a wide variety of user scenarios in order to uncover and isolate audio glitches.
In addition, the Devices & Media Performance team created a graphical tool to highlight glitches as well as the CPU activities that occurred before and during an audio glitch, which allows us to quickly diagnose any glitching problems that we uncover. For example, in the figure shown below, we can see a visual representation of when glitches occurred, and we can display related measurements that occurred at the time of the glitching in order to easily pinpoint any suspicious behavior.
Figure 5: Example Graphical View of Audio Glitch Troubleshooting
In this case, you can see four audio glitches (shown by red vertical lines in the top panel). Two panels down, we have displayed calls to the CPU that took longer than 3ms (called long ISRs/DPCs). In this example, you can see a direct correlation between audio glitches and long ISRs and DPCs, which are procedure calls executed by the operating system that have the potential to hog the CPU and produce audio glitches. From here, we can track down the components responsible for these calls in order to reduce or eliminate the glitching. This figure shows additional information than what we used to diagnose the particular problem discussed above; however, this information and the many other measurements are available to diagnose other glitches and media performance issues from across a wide range of sources.
Armed with these tests and tools, our next step was to deploy them on as many systems as possible. As part of this effort, we are participating in a Windows-wide initiative to help OEMs test their PCs at or before ship time. Hundreds of OEM machines get shipped to Microsoft for use in our Windows lab where we run thousands of tests in order to validate and ensure the best user experience. What this means is that if we notice that a particular machine or configuration might be susceptible to glitching, we can work with the OEM to try to fix the problem before the consumer ever sees their new PC.
By running these tests and analyzing the results with our new tools, we’ve been able to find hundreds of potential issues that would result in audio glitches. In some cases, this analysis resulted in changes to the Windows code. In other cases, we have identified components developed by our partners that can lead to audio glitching.
Since the issues we identify with these tools often involve components from many different partners, an important aspect of this work is engaging with these partners. Until now, it has been almost impossible for manufacturers to know how their components will affect the system as a whole, but by making these tests and tools available, we are attempting enable these partners to see how their components interact and what the final impact on users will be.
As part of this effort, we have been working to ensure that our partners can take full advantage of these new tools and tests. We’ve talked with OEMs, ODMs (original design manufacturers, who traditionally assemble the PC for the OEM), hardware manufacturers, and software vendors. We’ve given presentations and tutorials, written whitepapers, and held video conference workshops. Our goal has been to make it as easy as possible to create glitch-resilient software and hardware.
In summary, this effort includes:
Ultimately, we and all of our Windows partners share a common customer (you!); by working with our partners, calling attention to these issues, and providing more insight into the root causes of audio glitching, we are continue to improve the audio experience for everyone.
Delivering a new release of Windows includes a major effort to insure that applications continue to function as well on the new release as they have on the previous release. At the PDC we talked about some of the new areas of Windows Vista that reduced this level of compatibility, such as changes we made around the OS security model. With Windows 7 we renewed our engineering efforts to maintain compatibility. As with device testing, compatibility testing is an effort that spans the entire engineering organization, though we also have a group that is dedicated to this effort. This post was authored by a set of folks and coordinated by Grant George, the corporate vice president for testing in the Windows Experience team. --Steven
We have taken a very proactive approach to Application Compatibility and our process starts from the moment we first plan our product schedule and design and check in code for Windows and runs through all of our engineering processes and disciplines leading up to our final release (and beyond).
Our main Application Compatibility goal for Windows 7 is to make sure that most all applications which work on Windows Vista will continue to work seamlessly on Windows 7. We do have to be careful about making this claim to be universal because there is a class of applications that are always updated in tandem with a new Windows release. These applications are primarily system utilities, diagnostics, and security software—the common thread is that they make assumptions about the underlying implementation of Windows internals and thus require updates. We carefully coordinate with a large set of ISVs who provide these applications. This was talked about earlier this month as we announced our Ecosystem Readiness Program, which we will discuss more below.
At the start of our product cycle we review our new features and changed designs to ensure that every element of Windows 7 has Application Compatibility in mind. Our engineering process includes automated quality checks to assure public APIs don’t change, and our test engineers have the right tools, engineering time and information that is used to find application issues as early as possible in our development cycle. Telemetry information is collected to assess and prioritize the breadth of applications our users depend on, paired with market data and install base information, across a wide variety of software categories to make sure they work as expected in our new OS version.
Below we expand on how we deliver on this goal.
Rich telemetry from external usage and the broad software marketplace helps us to provide a list of the most popular and critical applications, updated frequently throughout our development cycle. Our engineers then acquire these applications and build automated tests that verify each one works as expected on Windows 7.
Changes that could impact application compatibility are followed up closely, for example Legacy Code Removal which involves removing code that existed in the previous release of the product is strictly guarded and tightly managed and should not happen without proper documentation and engagement with the impacted parties. For example if we need to deprecate an API call, the documentation for this API will be updated and we will wait until the impact of the removal is minimal as indicated by telemetry data unless it is required sooner to fix a security issue.
Throughout the development process we are running tests in the background creating an ongoing validation of new code relative to application compatibility. As code is getting ready to be checked into the main build, if a compatibility failure is detected in an automated regression test the checkin is halted. At that point the code is scanned for known compatibility issues and if an issue is detected the developer is asked to fix the problem. Of course we also develop new tests throughout the course of developing Windows 7 in order to broaden our coverage of third party software.
We have several teams dedicated to application compatibility as part of the Windows development effort. These teams provides guidance on how to build in application compatibility, provides data on application dependencies, and information on what applications may be impacted for any particular change we make in the Windows platform. These teams also reviews new feature designs, as well as other planned changes, to ensure that the engineering team has fully taken application compatibility into account so that we achieve the tenet of "keeping applications working on Windows 7".
In addition to working with the internal Windows engineering teams, we also reach out to 3rd party developers writing Windows applications to ensure these partners have all the information they need to make their solutions fully compatible with Windows Vista and Windows 7. Furthermore if we do uncover any issues that may need to be resolved by the 3rd party developers, we collect all the information, resources and guidance and engage in a conversation with those external developers to help them understand and fix these issues.
We recently announced the Windows 7 Ecosystem Readiness Program. This program provides partners with access to Windows 7 builds and tools they need to test solutions for Windows 7, Windows Vista, Windows Server 2008 and Windows Server 2008 R2. The Ecosystem Readiness Program also facilitates testing multiple components of the ecosystem together to improve the overall user experience. Rather than just focusing on getting a specific OEM product, software application, or hardware device certified, we will be bringing multiple components together to verify a rich user experience that delivers quality, reliability, and performance as well as innovation through new feature adoption.
As mentioned earlier we use telemetry data and market share information to choose the applications we directly test on as part of our compatibility efforts, below you can find the a sample of the Consumer Scenarios we focus our testing on:
To view a full list of Application Categories covered please take a look at the Appendix section at the end of this post. While we would love to provide the detailed list of products, several of the sources of this information are based on proprietary research from third parties.
Another very important set of technologies we test on are the middle tier technologies like Java, the .Net Framework, etc. to make sure the applications that use these technologies continue working as expected
In addition to 3rd party stand alone applications we test a subset of OEM pre-installed software and their inbox applications for compatibility. The software tested come from the engagements we have with our OEM partners and their submitted installation images. These images are tested on clean installations of Windows 7 and upgrades from Windows Vista on OPEM standard hardware. This level of coverage allows us to best replicate the initial experience with Windows 7 for many of our customers. Because many of these applications are closely aligned with the OS, hardware and drivers, it is not unusual for an OEM to provide updates to this software with a new OS release.
In addition to the above mentioned testing approaches, Microsoft IT maintains a software portfolio of approximately 1,500 applications. These applications must be tested prior to software deployments inside Microsoft.
Microsoft IT developed an application-tracking method that simplified the process of selecting applications for sample-based testing. By identifying groups of applications that have similar data processing, controls, underlying technology, and methods, Microsoft IT is able to test approximately 4 to 6 percent of the total applications and gain a reasonable assurance of compatibility for all.
For more information you can read the LOB Application Compatibility Technical White Paper.
Part of our testing process includes the creation of scenarios that we validate on 3rd party applications. We approach this by verifying the intended functionality of the application while focusing some of our attention to changes in the OS, new functionality and risky integration areas. Manual and automated test passes are scheduled to cover the identified scenarios and to verify the user experience. We cover the applications on different sets of hardware and make sure that that we cover a lot of different configurations, x86, x64, Intel, AMD, touch and multi -touch machines, etc.
We use specific categories when measuring the compatibility of the applications we test on:
We will cover these categories in more detail in subsequent blog posts about how we manage application compatibility.
As part of our testing we do find issues that may need to be resolved by the 3rd party developers at the companies that develop and sell these applications. We collect all of the relevant technical information, resources and guidance and engage in a conversation with those external partners to help them fix the issues. Of course we also engage them in our technical beta programs so they can test Windows 7 compatibility with their products at the same time we do.
Application compatibility is very important to the Windows team. We are constantly working to improve your experience with applications as you move from one release of Windows to the next. We encourage you to try our Windows 7 beta release to experience the improvements in the application compatibility space and we want to hear your feedback.
It is worth mentioning the work we have done from an end-user perspective to assist in application compatibility. Many failures of application compatibility happen at install time and to assist with this, in Windows 7 we have improved the detection of failed installations and provided a step by step wizard which will help to get an application’s “compatibility mode” correctly set. We also provide real-time problem reports and solutions that can help you locate an updated version or patch. Many of you might have experienced this when trying to run Skype after an upgrade or install the current version, and in both cases you were automatically referred to the Beta download site.
Microsoft Covered Consumer Scenarios & Application Categories
Our list includes the top 50% best selling applications in the past 24 months, some of this data is collected and aggregated from several well-known third party research information providers.
This has been a busy couple of days for a few of us on the team as we had a report of a bug in Windows 7. The specifics of the issue are probably not as important as a discussion over how we will manage these types of situations down the road and so it seems like a good time to provide some context and illustrate our process, using this recent example.
This week a report on a blog described a crashing issue in Windows 7. The steps to reproduce the crash were pretty easy (1) run chkdsk /r on a non-system drive then crash after consuming system memory. Because it was easy to “reproduce”, the reports of this issue spread quickly. Subsequent posts and the comments across the posts indicated that the issue seemed to have been reproduced by others—that is the two characteristics of the report were seen (a) consumption of lots of memory and (b) crashing.
Pretty quickly, I started getting a lot of mail personally on the report. Like many of you, the first thing I did was try it out. And as you might imagine I did not reproduce both issues, though I did see the memory usage. I tried it on another machine and saw the same behavior. In both cases the machine functioned normally during and after the chkdsk. As I frequently do, I answered most of the mail I receive and started asking people for steps to reproduce the crash and to share system dump files. The memory usage did not worry me quite as much as the crash. I began having a number of interesting mail threads, but we didn’t have any leads on a repro case nor did we have a crash dump to work with.
Of course I was not the first Microsoft person to see this. The file system team immediately began to look into the issue. They too were unable to reproduce the crash and from their perspective the memory usage was by design and was a specific Windows 7 change for this scenario (the /r flag grabs an exclusive lock and repairs a disk and so our assumption is you’d really like the disk to be fixed before you do more stuff on the machine, an assumption validated by several subsequent third party blog posts on this topic). We cast the net further and continued looking for crash dumps and reports. As described below we have quite a few tools at our disposal.
While we continued to investigate, the mail I was getting was escalating in tone and more importantly one of the people I responded to mentioned our email exchange in a blog post. So in my effort to have a normal email dialog I ended up in the thick of the discussion. As I have done quite routinely during the development of Windows 7, I added a comment on the original blog (and the blog where this particular email friend was commenting) outlining the steps we are taking and the information we knew to date. Interestingly (though not unfortunately) just posting the comment drew even more attention to the issue being raised. I personally love being a member of the broader community and enjoy being a casual contributor even when it seems to cause a bit of a stir.
It is worth just describing the internal process that goes on when we receive a report of a crashing issue. Years ago we had one of two reactions. Either we would just throw up our arms and surrender as we had no hope of finding the bug, or we would drop everything and start putting people on airplanes with terminal debuggers in the hopes of finding a reproducible case. Neither of these is particularly effective and the latter, while very heroic sounding, does not yield results commensurate with effort. Most importantly while there might be a crash, we had no idea if that was the only instance or if lots more people were seeing or would see the crash. We were working without any data to inform our decisions.
With the internet and telemetry built into our products (not just Windows 7) we now have a much clearer view of the overall health of the software. So when we first hear a report of a crash we check to see if we’re seeing the crash happen on the millions of machines that are out there. This helps us in aggregate, but of course does not help us if a crash is one specific configuration. However, a crash that is one specific configuration will still show up if there is any statistically relevant sampling of machines and given the size of the user base this is almost certain to be the case. We’re able to, for example, query the call stacks of all crashes reported to see if a particular program is on the stack.
We have a number of tools at our disposal if we are seeing a crash in telemetry. You might have even seen these at work if you crash. We can increase (with consent) the amount of data asked for. We can put up a knowledge base article as a response to a crash (and you are notified in the Windows 7 Action Center). We can even say “hey call us”. As crazy as that one might sound, sometimes that is what can help. If a crashing issue in an already shipping product suddenly appears then something changed—a new hardware device, new device driver, or other software likely caused the crash to appear far more frequently. Often a simple confirmation of what changed helps us to diagnose the issue. I remember one of the first times we saw this was when one day unexpectedly Word started crashing for people. We hadn’t changed anything. It turned out a new version of a popular add-in released and the crash was happening in the add-in, but of course end-users only saw Word crashing. We quickly put up instructions to remove the add-in while in parallel working with the ISV to push out a fix. This ability to see the changing landscape, diagnose, and respond to a problem has radically changed how we think of issues in the product.
We are constantly investigating both new and frequently occurring issues (including crashes, hangs, device not found, setup failures, potential security issues, and so on). In fact we probably look into on the order of hundreds of issues in any given month as we work with our enterprise and OEM customers (and therefore hardware partners, ISVs, etc.). Often we find that issues are resolved by code changes outside core Windows code (such as with drivers, firmware, or ISV code). This isn’t about dodging responsibility but helping to fix things at the root cause. And we also make many code changes in Windows, which are seen as monthly updates, hotfixes, and then service pack rollups. The vast majority of things we fix are not applicable broadly and hence not released with immediate urgency—if something is ever broadly applicable we will make the call to release it broadly. It is very important for everyone to understand how seriously we take the responsibility of making sure there are no critical issues impacting a broad set of customers, while also balancing the volume of changes we push out broadly.
To be specific about the investigation around the chkdsk utility, let’s look at how we dove into this over the past couple of days. We first looked through our crash telemetry (both at the user level and “blue screen” level) and found no reported crashes of chkdsk. We of course look through our existing reports of issues that came up during the development of Windows 7, but we didn’t see anything at all there. We queried the call stacks of existing reported crashes (of all kinds, since this was reported) and we did not find any crashes with chkdsk.exe running while crashing. We then began automated test runs on a broad set of machines—these ran overnight and continued for 2 days. We also saw reports related to a specific hardware configuration, so we set up over 40 machines based on variants of that chipset, driver, and firmware and ran those tests. We were not hitting any crashes (as mentioned, the memory usage was already understood). Because some were saying the machines were non-responsive we also looked for that in manual tests and didn’t see anything. We also broadened this to request globally to Microsoft folks to try things out (we have quite a few unique configs when you think of all of our offices around the world) and so we had several hundred more test runs going. We also had reports of the crash happening when running without a pagefile—that could be the case, but that would not be an issue with this utility as any program that requests more memory than physically available would cause things to tip over and this configuration is not recommended for general purpose use (and this appears to be the common thread on the small number of non-reproducible crashes). Folks interested might read Mark’s blog on the topic of pagefiles in general. While we did not identify anything of note, that does not rule out the possibility of a problem but at this point the chances of any broad issue are extremely small.
In the meantime, we continue to look through external blogs, forums and other reports of crashes to see if we can identify any reproducible cases of this. While we don’t contact everyone, we do contact people if the forum and report indicate this has a good chance of yield. In all fairness, it probably doesn’t help us when there’s a lot of “smoke” while we’re trying to find the fire. We had a lot of “showstopper” comments piling on but not a lot of additional data including a lack of a reproducible case or a crash dump.
This type of work will continue until we have satisfied ourselves that we have systematically ruled out a crash or defined the circumstances where a crash can happen. Because this is a hardware/software related issue we will also invite input from various IHVs on the topic. In this case, because it is disk related we can’t rule out the possibility that in fact the disk was either failing or about to fail and the excessive use of the disk during a /r repair would in fact generate a failure. And while the code is designed to handle these failures (as you can imagine) there is the possibility that the specific failure is itself not handled well. In fact, in our lab (running tests continuously for a few days) we had one failure in this regard and the crash was in the firmware of the controller for the disk. Obviously we’ll continue to investigate this particular issue.
I did want folks to know just how seriously we take these issues. Sometimes blogs and comments get very excited. When I see something like “showstopper” it gets my attention, but it also doesn’t help us to have a constructive and rational investigation. Large software projects are by nature extremely complex. They often have issues that are dependent on the environment and configuration. And as we know, often as deterministic as software is supposed to be sometimes issues don’t reproduce. We have a pretty clear process on how we investigate reports and we focus on making sure Windows remains healthy even in the face of a changing landscape. With this post, I wanted to offer a view into some specifics but also into the general issue of sounding alarms.
It is always cool to find a bug in software. Whether it is an ATM, movie ticket machine, or Windows we all feel a certain sense of pride in identifying something that doesn’t work like we think it should. Windows is a product of a lot of people, not just those of us at Microsoft. When something isn’t as it should be we work with a broad set of partners to make sure we can effectively work through the issue. I hope folks recognize how serious we take this responsibility as we all know we’re going to keep looking at issues and we will have issues in the future that will require us to change the code to maintain the level of quality we know everyone expects of Windows.
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:
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:
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.
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
Hi, Jon DeVaan here to talk to you about the recent UAC feedback we’ve been receiving.
Most of our work finishing Windows 7 is focused on responding to feedback. The UAC feedback is interesting on a few dimensions of engineering decision making process. I thought that exploring those dimensions would make for an interesting e7 blog entry. This is our third discussion about UAC and for those interested in the evolution of the feature in Windows it is worth seeing the two previous posts (post #1 and post #2) and also reading the comments from many of you.
We are flattered by the response to the Windows 7 beta so far and working hard at further refining the product based on feedback and telemetry as we work towards the Release Candidate. For all of us working on Windows it is humbling to know that our work affects so many people around the world. The recent feedback is showing us just how much passion people have for Windows! Again we are humbled and excited to be a part of an amazing community of people working to bring the value of computing to a billion people around the world. Thank you very much for all of the thoughts and comments you have contributed so far.
UAC is one of those features that has a broad spectrum of viewpoints with advocates staking out both “ends” of the spectrum as well as all points in between, and often doing so rather stridently. In this case we might represent the ends of the spectrum as “security” on one end and “usability” on the other. Of course, this is not in reality a bi-polar issue. There is a spectrum of perfectly viable design points in between. Security experts around the world have lived with this basic tension forever, and there have certainly been systems designed to be so secure that they are secure from the people who are supposed to benefit from them. A personal example I have, is that my bank recently changed the security regimen on its online banking site. It is so convoluted I am switching banks. Seriously!
As people have commented on our current UAC design (and people have commented on those comments) it is clear that there is conflation of a few things, and a set of misperceptions that need to be cleared up before we talk about the engineering decisions made on UAC. These engineering decisions have been made while we carry forth our secure development lifecycle principles pioneered in Windows XP SP2, and most importantly the principle of “secure by default” as part of SD3+C. Windows 7 upholds those principles and does so with a renewed focus on making sure everyone feels they are in control of their PC experience as we have talked about in many posts.
The first issue to untangle is about the difference between malware making it onto a PC and being run, versus what it can do once it is running. There has been no report of a way for malware to make it onto a PC without consent. All of the feedback so far concerns the behavior of UAC once malware has found its way onto the PC and is running. Microsoft’s position that the reports about UAC do not constitute a vulnerability is because the reports have not shown a way for malware to get onto the machine in the first place without express consent. Some people have taken the, “it’s not a vulnerability” position to mean we aren’t taking the other parts of the issue seriously. Please know we take all of the feedback we receive seriously.
The word “vulnerability” has a very specific meaning in the security area. Microsoft has one of the leading security agencies in the world in the Microsoft Security Response Center (email@example.com) which monitors the greater ecosystem for security threats and manages the response to any threat or vulnerability related to Microsoft products. By any definition that is generally accepted across the world wide security community, the recent feedback does not represent a vulnerability since it does not allow the malicious software to reach the computer in the first place.
It is worth pointing out the defenses that exist in Windows Vista that keep malware from getting on the PC in the first place. In using Internet Explorer (other browsers have similar security steps as well) when attempting to browse to a .vbs file or .exe file, for example, the person will see the prompts below:
Internet Explorer 8 has also introduced many new features to thwart malware distribution (see http://blogs.msdn.com/ie/archive/2008/08/29/trustworthy-browsing-with-ie8-summary.aspx ). One of my favorites is the SmartScreen® Filter which helps people understand when they are about to visit a malicious site. There are other features visible and hidden that make getting malware onto a PC much more difficult.
A SmartScreen® display from IE 8
Additionally, if one attempts to open an attachment in a modern email program (such as Windows Live Mail) the malware file is blocked:
Much of the recent feedback has failed to take into account the ways that Windows 7 is better than Windows Vista at preventing malware from reaching the PC in the first place. In Windows 7 we have continued to focus on improving the ability to stop malware before it is installed or running on a PC.
The second issue to untangle is about the difference in behavior between different UAC settings. In Windows 7, we have four settings for the UAC feature: “Never Notify,” “Notify me only when programs try to make changes to my computer (without desktop dimming),” “Notify me only when programs try to make changes to my computer (with desktop dimming),” and “Always Notify.” In Windows Vista there were only two choices, the equivalent of “Never Notify” and “Always Notify.” The Vista UI made it difficult for people to choose “Never Notify” and thus choosing between extremes in the implementation. Windows 7 offers you more choice and control over this feature, which is particularly interesting to many of you based on the feedback we have received.
The recent feedback on UAC is about the behavior of the “Notify me only when programs try to make changes to my computer” settings. The feedback has been clear it is not related to UAC set to “Always Notify.” So if anyone says something like, “UAC is broken,” it is easy to see they are mischaracterizing the feedback.
The Purpose of UAC
We are listening to the feedback on how “Notify me only when…” works in Windows 7. It is important to bring in some additional context when explaining our design choice. We choose our default settings to serve a broad range of customers, based on the feedback we have received about improving UAC as a whole. We have learned from our customers participating in the Customer Experience Improvement Program, Windows Feedback Panel, user surveys, user in field testing, and in house usability testing that the benefit of the information provided by the UAC consent dialog decreases substantially as the number of notifications increases. So for the general population, we know we have to present only key information to avoid the reflex to “answer yes”.
One important thing to know is that UAC is not a security boundary. UAC helps people be more secure, but it is not a cure all. UAC helps most by being the prompt before software is installed. This part of UAC is in full force when the “Notify me only when…” setting is used. UAC also prompts for other system wide changes that require administrator privileges which, considered in the abstract, would seem to be an effective counter-measure to malware after it is running, but the practical experience is that its effect is limited. For example, clever malware will avoid operations that require elevation. There are other human behavior factors which were discussed in our earlier blog posts (post #1 and post #2).
UAC also helps software developers improve their programs to run without requiring administrator privileges. The most effective way to secure a system against malware is to run with standard user privileges. As more software works well without administrator privileges, more people will run as standard user. We expect that anyone responsible for a set of Windows 7 machines (such as IT Administrators or the family helpdesk worker (like me!)) will administer them to use standard user accounts. The recent feedback has noted explicitly that running as standard user works well. Administrators also have Group Policy at their disposal to enforce the UAC setting to “Always Notify” if they choose to manage their machines with administrator accounts instead of standard user accounts.
Recapping the discussion so far, we know that the recent feedback does not represent a security vulnerability because malicious software would already need to be running on the system. We know that Windows 7 and IE8 together provide improved protection for users to prevent malware from making it onto their machines. We know that the feedback does not apply to the “Always Notify” setting of UAC; and we know that UAC is not 100% effective at stopping malware once it is running. One might ask, why does the “Notify me only when…” setting exist, and why is it the default?
The creation of the “Notify me only when…” setting and our choice of it as the default is a design choice along the spectrum inherent in security design as mentioned above. Before we started Windows 7 we certainly had a lot of feedback about how the Vista UAC feature displayed too many prompts. The new UAC setting is designed to be responsive to this feedback. A lot of the recent feedback has been of the form of, “I’ll set it to ‘Always Notify,’ but ‘regular people’ also need to be more secure.” I am sure security conscious people feel that way, and I am glad that Windows 7 has the setting that works great for their needs. But what do these so called “regular people” want? How to choose the default, while honoring our secure design principles, for these people is a very interesting question.
In making our choice for the default setting for the Windows 7 beta we monitored the behavior of two groups of regular people running the M3 build. Half were set to “Notify me only when…” and half to “Always Notify.” We analyzed the results and attitudes of these people to inform our choice. This study, along with our data from the Customer Experience Improvement Program, Windows Feedback Panel, user surveys, and in house usability testing, informed our choice for the beta, and informed the way we want to use telemetry from the beta to validate our final choice for the setting.
A key metric that came out of the study was the threshold of two prompts during a session. (A session is the time from power up to power down, or a day, whichever is shorter.) If people see more than two prompts in a session they feel that the prompts are irritating and interfering with their use of the computer. In comparing the two groups we found that the group with the “Always Notify” setting was nearly four times as likely to have sessions with more than two prompts (a 1 in 6.7 chance vs a 1 in 24 chance). We gathered the statistic for how many people in the sample had malware make it onto their machine (as measured by defender cleaning) and found there was no meaningful difference in malware infestation rates between the two groups. We will continue to collect data during the beta to see if these results hold true in a much broader study.
We are very happy with the positive feedback we have received about UAC from beta testers and individual users overall. This helps us validate our “regular people” focus in terms of the trade-offs we continue to consider in this design choice. We will continue to monitor the feedback and our telemetry data to continue to improve our design choices on UAC.
So as you can see there is a lot of depth to the discussion of UAC and the improvements made in Windows 7 in UAC itself and in improving ways to prevent malware from ever reaching a PC. We are working hard to be responsive to the feedback we received from Vista to provide the right usability and security for people of all types. We believe we’ve made good progress and are listening carefully to the feedback on our UAC changes. Again please accept our most sincere thanks for the passion and feedback on Windows 7. While we cannot implement features the way each and every one of you might wish, we are listening and making a sincere effort to properly weigh all points of view. Our goal is to create a useful, useable, and secure Windows for all types of people.
Microsoft has been a global software company for a long time and has always put a lot of effort into engineering our products for a global customer base. It is also an area where the engineering is complex—probably a lot more complex than many might think—and one where we are always trying to learn and improve. Building global software is a responsibility for everyone on the team. We also have feature teams dedicated to developing both global and market specific features—whether it is font handling or doing East Asian language input as two examples. We of course have a significant engineering effort that goes into localizing (“translating” is not quite accurate) Windows into nearly 100 languages. Julie Bennett represents the global development and localization teams and she and John McConnell on her team collaborated across the team to author this post that provides an overview of engineering for a global market. --Steven
Many of the readers of the e7 blog are located outside of the United States or speak a language other than English, so we thought it would be useful to share the international and multi-lingual improvements in Windows 7. Our goal for Windows 7 is to deliver exciting features that benefit users worldwide as well as features that make Windows feel local to every user. Like Windows 7's focus to improve the fundamental scenarios of performance and reliability, we improved our processes to allow us to deliver a great customer experience in every language and every country we serve, including delivery of Windows 7 as close to simultaneously as possible worldwide. This blog entry discusses some of the new features and improved processes that we believe make Windows 7 a great worldwide release.
The international features of Windows 7 are pervasive across the system, from such low-level aspects as the supported characters in NTFS file names (now upgraded to match Unicode 5.1) to such high-level aspects as the selection of backgrounds and themes (now including locally-relevant photos). But there are certain features which are intrinsically critical for proper support of the world’s many languages and cultures, and we will describe some of those here.
Language and writing are at the heart of any culture and thus support for fonts is essential to supporting international users. Windows 7 significantly increases both the range and quality of fonts. We have added fifty new fonts:
As you might guess from the font names in the above table, many of the new fonts are for non-Latin scripts. In fact, Windows 7 will be the first version of Windows to ship with more fonts for non-Latin scripts than for Latin-based scripts. One major area of improvement is for the languages of India. To the nine (9) fonts for Indian languages that shipped in Vista, Windows 7 adds forty (40) more. Windows 7 will now include multiple fonts (often in multiple weights) for each of the official languages of India.
Aparajita: A New Devanagari Font in Regular, Bold, Italic and Bold-Italic
Besides new fonts, we have also improved many of the existing fonts. For example, we have added over two thousand (2,000) glyphs to Consolas, Calibri, Cambria Bold, and Cambria Math. But the most dramatic improvements have been to some of the non-Latin scripts. For example, Windows 7 does a much better job rendering the common Lam-Alef ligature in Arabic (see the illustration below) and in the placement of vowel marks.
Left: Lam-Alef Ligture in Vista Right: Lam-Alef Ligature in Windows 7
Changes to fonts (even clear improvements) are always tricky because of backwards compatibility issues. For example, if a character changes width or position, it may cause existing documents to reflow (repaginate), which is unacceptable. Therefore, whenever we change a font, we must run extensive verification tests against the changes to ensure the font metrics and other tables are unchanged. In the case of the Lam-Alef fix shown above, we discovered that there were existing applications that relied on the (undocumented) order of the glyphs within the old font. These applications would break if we simply replaced the glyphs. The font team worked closely with the international application compatibility team to ensure that changes we made did not affect the order of glyphs within the font, thus providing backward compatibility.
With so many new and expanded fonts for Windows 7, we also wanted to help users manage their fonts more easily. For the first time in years, we have done a complete overhaul of the font control panel.
The first picture below shows the font control panel with the large icon view. The most obvious change is that the font icons now convey much more information about the appearance of the font. The content of the icon gives a hint as to the glyph repertoire of the font. The style of the icon matches the style of the font. Non-Latin fonts show typical glyphs from the script for the font to see how it is designed. A more subtle change is that some font icons are faded to indicate fonts that are installed, but hidden. Hidden fonts will not show by default in the ribbon and font dialogs. Users can now use the font control panel to tune the fonts that they regularly use. By hiding fonts they never use, users can simplify choosing the correct font within applications. By default, only fonts supporting languages that can be written with the users installed input locales (keyboard layout plus language) will be shown. For example, users with English and French input locales will see only the Latin fonts, whereas users with the Japanese input method installed will see only the Japanese fonts. Users can override these defaults by right-clicking on any of the fonts in the control panel. Hidden fonts are still installed so an existing application that uses a hidden font will behave identically.
Font Control Panel with Large Icon View
The next picture below shows the font control panel with the detailed view. Now users can see much more information about the font. For example, the user can sort fonts by style, whether they are hidden, and information about the creator of the font. Font files generally contain information only in the design language of the font (e.g. a Japanese font might contain only information in Japanese). In Windows 7, we needed a solution that would work for all languages and for all fonts, so we created a hybrid approach that combines information from the font itself with metadata (an XML file that provides the information about the fonts on the system).
Font Control Panel with Detail View
Windows 7 has increased opportunities for personalization. New themes, backgrounds, and sounds make it easy to customize Windows 7 to match your personality. To the extent that our preferences are influenced by our language and location, Windows 7 reflects this with the introduction of Local Packs. Local Packs provide customized Windows 7 visual themes for a specific region. These visual themes contain locally relevant wallpaper images, custom aero glass colors, and regional sound schemes. Windows® Internet Explorer® Favorites and RSS feeds may also be updated when the Local Pack is activated on an end user’s computer. For example, adding and enabling the Local Pack for France will add a market-customized theme for France to the end user’s Personalization control panel and a number of links to useful French Public Sector websites and RSS Feeds to the user’s profile.
Customized Themes in the Personalization control panel
The Local Pack content provides users with seamless local experiences right out of the box. Users are never exposed to Local Packs per se, they just select their Location as normal during Windows Welcome, and appropriate local content is exposed to them based on that setting.
Users looking for visual themes for other countries, or indeed any other areas of interest, can find them on the Windows Online Gallery, which is accessible via the “Get more themes online” link in the Personalization control panel.
Other new features include five (5) new locales (bringing the total number of locales supported to two hundred and ten (210)), twelve (12) new input locales, and improvements to sorting for traditional Chinese characters. Also, we have generally updated our system databases to the latest version of the Unicode Standard (5.1). There are also interface improvements that should allow developers to create better globalized applications. Extended Linguistic Services (ELS) is a cool new feature we describe below in the International Timeliness and Quality section.
Perhaps one of the most important improvements outside the core international features has been in Search, which now recognizes more languages. For example, Windows 7 desktop search now recognizes Russian morphology (the rules for single and plural, tenses, and case). This means that searches for a particular word in Russian will now match not only that exact word, but also the common variations of the word, yielding significantly better results.
In previous versions of Windows, final delivery of every language to every market took several months. For Windows 7, we changed how we worked on international releases to significantly shorten this delta so that all users worldwide can enjoy Windows as simultaneously as possible. This goal had far reaching implications on how we perform our work as engineers and on how we interact with partners and customers during our public testing phases.
To understand our approach, we should first explain two important concepts: localization and globalization.
Localization is the process of adapting the user experience into another language. Beyond the translation of strings, it can also include activities such as resizing dialogs and mirroring icons for right-to-left languages, such as Hebrew and Arabic. Localization bugs, such as the mistranslation of a menu item, are defects introduced during this process.
Globalization, on the other hand, is the process of producing a product that works well in every country no matter the user interface language setting. A globalization bug may be as simple as showing a UI element in the wrong language and as complex as not properly handling right-to-left scripts. Globalization bugs are inherently more serious than localization bugs as they usually affect many or all languages and often require re-thinking the technical design. In past Windows releases, repairing globalization bugs contributed to the necessity of the long release deltas. For Windows 7 we worked to prevent, find, and fix globalization bugs as early in the development process as possible.
To prevent common globalization bugs, pseudo-localized builds were created. Pseudo-localization is a process that creates a localized product in an artificial language. That language is identical to English except that each character is written with a different character that visually resembles the English character. Except for being entirely machine generated, we create the pseudo-localized builds exactly the same way as we create the localized builds. Because even monolingual US software developers can read pseudo-localized text, it has proven to be an excellent way to find globalization problems early in the development cycle. In the Windows 7 beta, some UI elements were still in their pseudo-localized form, causing some interesting theories about what the meaning might be. We hope we have solved the mystery with this blog post. :-)
Control Panel Dialog in Pseudo-localized Windows 7
Beta is always an exciting time for us as it is our first real chance to hear from you about our efforts. We are thrilled that people from over one hundred and thirteen (113) countries downloaded the Windows 7 Beta. With such a large and diverse beta program, we must have highly scalable processes to gather and incorporate your feedback. In Windows 7, we are very excited about some new approaches we took here.
In the past, localization languages for Windows beta releases were selected for a mix of pragmatic reasons. While this ad hoc approach had benefits, too often we found that serious globalization defects were not reported because they did not manifest in the chosen languages. For the Windows 7 Beta, our priority was to find globalization bugs and therefore we have concentrated on four languages (plus English) that experience has shown are most likely to find specific types of defects:
By concentrating on these four languages during Beta, we maximized our chances to find and fix the globalization bugs that affect many languages. This in turn gave us more time to improve the localization of all languages before we release the actual product. The pictures below show two bugs found during Beta that illustrate the advantages of focusing on these pilot languages.
Globalization Defects Found During Windows 7 Beta
In addition to our goal of finding globalization bugs via these languages, we also asked some of our OEM customers to provide feedback on the language aspects within their manufacturing processes. Since many of the OEMs are located in East Asia, we also localized Windows 7 Beta for Simplified Chinese, Traditional Chinese, and Korean.
In part because of the engineering process improvements described above, we were able to deliver more language packs for Windows 7 RC than we have ever been able to do in the past for Windows. For those of you running the Ultimate version of Windows 7 RC, you will have noticed the following thirty-two (32) Language Packs available for download on Windows Update:
32 Windows 7 RC Language Packs on Windows Update
One thing we will do differently in the future is to ensure that all languages available at Beta are also available at RC (e.g. not including Hindi for Windows 7 RC). We will correct this for future versions.
With Windows 7 beta localized into five languages and globally enabled for hundreds more, we received beta bugs from customers all over the world. We rely on these bug reports to help us improve Windows 7, so we devote much time to reading customer bug reports to determine product issues. Because bugs come from worldwide customers in many languages, we look for ways not only to understand their feedback, but also to address it as quickly as possible. The faster we can understand the issue, the better chance we have of addressing the feedback. As we receive bug reports in all the many languages that our customers speak, this has sometimes posed quite a challenge.
In the past, we have handled multilingual bug reports using manual processes, where individual bugs were examined and then manually translated one-by-one for appropriate follow-up by the feature team that owned the affected component. This is a time-consuming and error-prone exercise that scales poorly to a program as large and diverse as the Windows 7 beta. In the worst case, valuable international feedback has missed the window to affect the final product, and thus slipped to a Service Pack or subsequent release.
In Windows 7, by using the language detection API in the new Extended Linguistic Services (ELS), we have been able to automatically detect the language of customer bugs as they are reported. ELS functionality is new for Windows 7 and available to any developer who wants to leverage advanced linguistic functionality in the operating system. Beginning in Windows 7, developers may use ELS to provide language and script detection of any Unicode text, as well as transliteration to map text between writing systems. To use these Windows 7 services and all further services that we will add in subsequent releases, developers need only to learn one simple and unified interface. The ability to detect over one hundred (100) languages is available for all Windows 7 application developers, and we are happy to be able to apply this functionality to triage and handle beta feedback you send us from around the world. We use our own international developer functionality to improve our ability to respond to customer issues globally.
Once we have detected the language, we take the resulting text and use the machine translation support that is available online from Live Translator. This allows us to translate the text to English to get a sense of your feedback. Our engineers can then search our feedback database for specific features or areas of functionality. This also helps us in our efforts to ensure international application compatibility, as we can learn about potentially problematic international application experiences as soon as customers report them. Machine translation does not provide a perfect translation, but it does allow us to determine which issues might require further investigation. This in turn allows us to hear and respond to customer issues with a much faster turnaround time than we have had in previous releases, which means better quality in Windows 7 when we release it to the world.
By the end of Windows 7 Beta, we had used this process to translate 35,408 issues and comments submitted using the Feedback tool.
The end result of the work to improve globalization and localization quality is reflected in the announcement that all fully localized releases of Windows 7 will be available within two weeks of the initial release wave with all languages available in October. We hope (and believe!) end users will find the overall quality of these releases to be the best ever.
36 Windows 7 language releases available in October 2009
In addition to the 36 languages that will be released in October, there will be additional languages available for download as Language Interface Packs (LIPs) onto any Windows 7 edition as part of the Local Language Program (LLP). The LLP is a partnership with governments, universities, and language experts from around the world. (You can find more information on the LLP at http://www.microsoft.com/unlimitedpotential/programs/llp.mspx.) Work on a LIP starts at RTM and continues for many months based on the schedules of our partners. Two (2) LIPs will be available for download when Windows 7 is available in October – Catalan and Hindi. Additional LIPs will become available for download over the following months based on the schedules of our partners. We are happy to have improved the delivery time of the first 38 languages (36 + 2 LIPs) and recognize that future releases are an opportunity to improve further. Creating a track record of dependable release schedules on our part will help everyone around the world plan better for a more unified release timeline.
More information about Extended Linguistic Services (ELS) and other cool new features of Windows 7 are available on-line on MSDN. In particular, you can download the Windows SDK for Windows 7 and read about what is new in the ‘International’ section. Also, the new Go Global Developer Center on MSDN has a wealth of information about international technologies.
If you want to send us feedback, please comment on this blog entry or use the Feedback button in Windows 7. We love to hear from you (in any language).
-- Windows International Team
Today marks an important milestone in the Windows 7 project. The Windows 7 team is proud to share with you that a short while ago we have started to release Windows 7 to PC OEM and manufacturing partners. This means our next major milestone will be the availability of PCs loaded with Windows 7 and store shelves stocked with Windows 7 on October 22, 2009.
This is a milestone we could not have achieved without the broad participation across the PC Ecosystem we have talked so much about on this blog. Windows 7 is a product not just of Microsoft, but of a whole industry of partners of all kinds. Throughout the development of Windows 7 we’ve seen an incredible engagement from so many people that have contributed to making the Windows 7 engineering project one we, collectively, feel good about. The feedback and collaboration throughout the development of Windows 7 has been outstanding and valuable beyond measure. This work has created the kind of experience so many of you have talked about in this blog—the ability to use a broad range of PC hardware and peripherals with a great setup and out of box experience. On behalf of the Windows team and all of the successful installations and device connections, please let me extend an incredible “thank you” to all of our hardware partners who have done such excellent work.
Windows 7 has also been one of the most broadly and deeply tested releases of software we have ever had. Starting with a pre-beta in October of 2008 with a few thousand developers using Windows 7 at the earliest stages, through the Beta, and then the Release Candidate in May when we have had millions of people successfully running the product (and many on multiple PCs). As we have discussed in this forum, the ongoing depth usage of Windows 7 along with the breadth and variety of hardware and software configurations has provided (and will continue to provide) the key tools to make sure we continue to deliver ever-improving Operating System quality.
In developing Windows 7 we also set out to have a great dialog with you, perhaps our strongest critics and our biggest supporters. We know you expect a lot from Windows 7 and you demand a lot from the team that builds your OS. This blog has helped to bring significant issues and important decisions to light and we have debated them—here and elsewhere. Along the way we have definitely learned a lot about working together and also about many specific issues that are important to you. We have worked hard to find the right balance across many diverse points of view and we hope you share our feeling that we’ve done a good job at being open, honest, and transparent in how we have approached engineering Windows 7. The conversations we had on this blog have been a memorable part of developing Windows 7 and in our hallways, in Redmond and around the world, we’ve spent collectively thousands of hours discussing and acting on the feedback you have provided here.
While we have reached our RTM Milestone, no software project is ever really “done”. We will continue to monitor and act on the real world experience with Windows 7—we’ve used the Beta and RC process to test out our servicing and we have every intent of doing a great job on this important aspect of the product. Hardware partners will continue to provide new devices and improve support for existing devices. PC makers no doubt have quite a bit in store for all of us as they begin to show off PCs specifically designed for Windows 7’s new APIs and features. Software developers will have lots of new software to show off as well. All of this is yet to come and is very exciting.
Software projects on the scale of Windows are pretty rare and our team has a lot of pride, and as we have said so many times, is humbled by the responsibility. We are going to continue to learn and continue to improve how we engineer our products, with the aim of being the very best engineers we can be and delivering the very best OS for the world’s varied customers. Being an engineer is about learning and that learning comes from the experience gained in designing and delivering each release. Together we’ve learned and together we’ve engineered a wonderful product.
We know there are lots of questions about how to get Windows 7 and when, and of course more questions to come about exploring and using the full set of Windows 7 features. Our Windows Team Blog today has posted a lot of new information and gathered up some important details that we hope will answer your questions. Please check our blog and stay in touch on the in-market developments of Windows 7 there.
The final few minutes before RTM are a sign-off process where each and every team that contributed to Windows formally commits to having successfully executed the work necessary for the product to be in the release process. We gather one last time (for Windows 7) in the “Ship Room” and a representative from each team signs (literally) and signifies their team’s readiness for manufacturing. We thought we’d share this moment with you here today.
On behalf of the Windows 7 engineering team we want to thank you very much for your contributions throughout development and your contributions yet to come to Windows 7. THANK YOU!
Next stop, October 22, 2009!
--The Windows 7 team
We’ve booted the machine, displayed stuff on the screen, launched programs, so next up we’re going to look at a pretty complex topic that sort of gets to the core role of the graphical user interface—managing windows. Dave Matthews is program manager on the core user experience team who will provide some of the data and insights that are going into engineering Windows 7. --Steven
The namesake of the Windows product line is the simple “window” – the UI concept that keeps related pieces information and controls organized on screen. We’ll use this post to share some of the background thinking and “pm philosophy” behind planning an update to this well established UI feature.
The basic idea of using windows to organize UI isn’t new – it dates back (so I hear) to the first experiments with graphical user interfaces at Stanford over 40 years ago. It’s still used after all this time because it’s a useful way to present content, and people like having control over how their screen space is used. The “moveable windows” feature isn’t absolutely needed in an operating system – most cell phones and media center type devices just show one page of UI at a time – but it’s useful when multi-tasking or working with more than one app at a time. Windows 2.0 was the first Windows release that allowed moveable overlapping windows (in Window 1.0 they were only able to be tiled, not overlapping. This “tiled v. overlapping” debate had famous proponents on each side—on one side was Bill Gates and on the other side was Charles Simonyi). In addition, Windows also has the unique notion of "the multiple document interface” or MDI, which allows one frame window to itself organized multiple windows within it. This is somewhat of a precursor to the tabbed interfaces prevalent in web browsers.
As a side note, one of the earlier debates that accompanied the “tiled v. overlapping” conversations in the early Windows project was over having one menu bar at the top of the screen or a copy of the menu bar for each window (or document or application). Early on this was a big debate because there was such limited screen resolution (VGA, 640x480) that the redundancy of the menu bar was a real-estate problem. In today’s large scale monitors this redundancy is more of an asset as getting to the UI elements with a mouse or just visually identifying elements requires much less movement. Go figure!
From Windows 2.0 to Vista.
An area I’ve been focusing on is in the “window management” part of the system – specifically the features involved in moving and arranging windows on screen (these are different than the window switching controls like the taskbar and alt-tab, but closely related). In general, people expect windows to be moveable, resizable, maximizable, minimizable, closeable; and expect them to be freely arranged and overlapping, with the currently used window sitting on top. These transformations and the supporting tools (caption buttons, resize bars, etc) make up the basic capabilities that let people arrange and organize their workspace to their liking.
In order to improve on a feature area like this we look closely at the current system - what have we got, and what works? This means looking at the way it’s being used in the marketplace by ISVs, and the way it’s used and understood by customers.
Caption buttons give a simple way to minimize, maximize, and close. Resizable windows can be adjusted from any of their 4 edges.
As pointed out in the previous Taskbar post, on average people will have up to 6 – 9 windows open during a session. But from looking at customer data, we find that most time is spent with only one or two windows actually visible on screen at any given time. It’s common to switch around between the various open windows, but for the most part only a few are visible at once.
Windows Feedback Panel data
As part of our planning, we looked at how people spend their time and energy in moving and sizing their windows. This lets us understand what’s working well in the current system, and what could be improved.
For example, we know that maximize is a widely used feature because it optimizes the work space for one window, while still being easy to switch to others. Users respond to that concept and understand it. Since most of the time users just focus on one window, this ends up being very commonly used. We know that for many applications people ask for every single pixel (for example spreadsheets where a few pixels gain a whole extra row of column) and thus the beyond maximize features for “full screen” become common, even for everyday productivity.
An issue we've heard (as recently as the comments on the taskbar post!) with maximize in Vista is that the customized glass color isn’t very visible, because the windows and taskbar become dark when a window is maximized. (In Vista you can customize the glass window color – and in 29% of sessions a custom color has been set). The darker look was used to help make it clear that the window is in the special maximized state. This was important because if you don’t notice that a window is maximized and then try to move it, nothing will happen - and that can be frustrating or confusing. For Windows 7 we’re looking at a different approach so that the customized color can be shown even when a window is maximized.
Interestingly, people don’t always maximize their windows even when they’re only using one window at a time. We believe one important reason is that it’s often more comfortable to read a text document when the window is not too wide. The idea of maximizing is less useful on a wide monitor when it makes the sentences in an email run 20+ inches across the screen; 4 or 5 inches tends to be a more pleasant way to read text. This is important because large desktop monitors are becoming more common, and wide-aspect monitors are gaining popularity even on laptops. Since Windows doesn’t have a maximize mode designed for reading like this, people end up manually resizing their windows to make them as tall as possible, but only somewhat wide. This is one of the areas where a common task like reading a document involves excessive fiddling with window sizes, because the system wasn’t optimized for that scenario on current hardwarwe.
Resolution data suggests wide aspect-ratio monitors will become the norm.
Being able to see two windows side by side is also a fairly common need. There are a variety of reasons why someone may need to do this – comparing documents, referring from one document into another, copying from one document or folder into another, etc. It takes a number of mouse movements to set up two windows side by side – positioning and adjusting the two windows until they are sized to roughly half the screen. We often see this with two applications, such as comparing a document in a word processor with the same document in a portable reader format.
Users with multiple monitors get a general increase in task efficiency because that setup is optimized for the case of using more than one window at once. For example, it’s easy to maximize a window on each of the monitors in order to efficiently use the screen space. In a Microsoft Research study on multi-tasking, it was found that participants who had multiple monitors were able to switch windows more often by directly clicking on a window rather than using the taskbar, implying that the window they want to switch to was already visible. And interestingly, the total number of switches between windows was lower. In terms of task efficiency, the best click is an avoided click.
MSR research report
Single monitor machines are more common than multi-mon machines, but the window managing features aren’t optimized for viewing multiple windows at once on one monitor. The taskbar does has context menu options for cascade, stack, or side-by-side, but we don't believe they're well understood or widely used, so most people end up manually resizing and moving their windows whenever they want to view two windows side by side.
An interesting multiple window scenario occurs when one of the windows is actually the desktop. The desktop is still commonly used as a storage folder for important or recent files, and we believe people fairly often need to drag and drop between the desktop and an explorer window, email, or document. The “Show Desktop” feature gives quick access to the desktop, but also hides the window you're trying to use. This means you either have to find and switch back to the original window, or avoid the Show Desktop feature and minimize everything manually. It’s very interesting to see scenarios like this where the people end up spending a lot of time or effort managing windows in order complete a simple task. This kind of experience comes across in our telemetry when we see complex sequences repeated. It takes further work to see if these are common errors or if people are trying to accomplish a multi-step task.
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:
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.
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.
Our taskbar made its debut way back in Windows 95 and its core functionality remains the same to this day. In short, it provides launching, switching and “whispering” functionality. Figure 1 shows the Vista taskbar and calls out its basic anatomy. Notable pieces are the taskband, Quick Launch, the Start Menu, Desktop Toolbars (aka Deskbands) and the Notification Area. Collectively, these components afford some of the most fundamental controls for customers to start, manage and monitor their tasks.
Fig. 1: Windows Taskbar Anatomy
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 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 provides a way for customers to launch commonly used programs, files, folders and websites directly off the taskbar. It was introduced to Windows 95 by Internet Explorer 4.0 with the Windows Desktop Update. Customizing Quick Launch is as simple as dragging shortcuts into to this area. It saves you a trip to the Start Menu, the desktop or a folder when you want to launch something. An interesting feature of Quick Launch that you may not be aware of is that it has always supported large icons (unlock the taskbar, right-click on Quick Launch and click on large icons under “View”) as seen in figure 2. Of course growing the icons begins to intrude on the real-estate of the taskband which is one of the reasons we have not enabled this configuration by default. As an aside, Windows XP had Quick Launch turned off by default in an attempt to reduce the number of different launching surfaces throughout Windows. Based on your feedback, we quickly rectified this faux pas and Quick Launch was turned on by default again. Don’t mess with quick access to things people use every day! We heard you loud and clear.
Fig. 2: Large Icons in Quick Launch. Large icons on the taskbar have been supported since Windows 95 with IE 4
Desktop Toolbars 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.
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.
Earlier posts to this blog discussed how customers can voluntarily and anonymously send us data on how they use our features. We use these findings to help guide our designs. Please note that data do not design features for us, but they certainly help us prioritize our investments as well as validate our approach. All to often we’re all guilty of saying something like “we know everyone does <x>” or “all users do <y>”. Given the reliability and statistical accuracy of this data, we can speak with more real-world accuracy about how things are in used in practice. Let’s look at some interesting information we have collected about how our customers use the taskbar.
Figure 3 provides some of the most important data about the taskbar—window count. On average, we know that a vast majority of our customers encounter up to 6-9 simultaneous windows during a session (a session is defined as a log in / log out or 24 hours—whichever occurs first). It goes without saying that the taskbar should work for the entire distribution of this graph, but identifying the “sweet spot” helps focus our efforts on the area that matters most to the most amount of customers. So, we know that if we nail the 6-9 case and we work well for the 0-5 as well as the 10-14 scenarios, we’ve addressed almost 90% of typical sessions.
Fig. 3: What’s the maximum number of windows opened at a time?
Figures 4 and 5 help us understand how customers customize their taskbars. We could probably spend an entire post focused solely on how we determine the options we expose. Perhaps another time we’ll tackle the paradox of choice and how options stress our engineering process yet also make the product more fun for a set of customers. Until then, let’s see what conclusions we can draw from these findings. The most obvious takeaway is that most customers do not change the default settings, which are a simple right-click Properties away. For example, it may be interesting to note how often end-users relocate the taskbar to other regions of the screen—less than 2% of sessions have a taskbar that’s not at the bottom of the screen. We also know that some small percentage of machines accidently relocate the taskbar and more often than not end-users have difficulty undoing such a state—though our data does not differentiate this situation. This data does not necessarily mean we would remove relocation functionality, but rather we could prioritize investments in a default horizontal taskbar over other configurations.
Fig. 4: How do people customize their taskbar? The red number indicates percentage of sessions in which the corresponding checkbox is enabled.
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.
Toolbar enabled and visible
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.
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.
In the abstract, we can summarize this feedback with a few principles:
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.
One of the cool results of this dialog is how much interest there is in diving into the details and data behind some of the topics as expressed in the comment and emails. We’re having fun talking in more depth about these questions and observations. This post is a follow-up to the comments about high DPI resolution, application compatibility, and the general problems with readability in many situations. Allow me to introduce a program manager lead on our Desktop Graphics team, Ryan Haveson, who will expand on our discussion of graphics and Windows 7. –Steven
When we started windows 7 planning, we looked at customer data for display hardware, and we found something very interesting (and surprising). We found that roughly half of users were not configuring their PC to use the full native screen resolution. Here is a table representing data we obtained from the Windows Feedback Program which Christina talked about in an earlier post.
We don't have a way of knowing for sure why users adjust their screen resolution down, but many of the comments we’ve seen match our hypothesis that a lot of people do this to because they have difficulty reading default text on high resolutions displays. With that said, some users probably stumble into this configuration by accident; for example due to a mismatched display driver or an application that changed the resolution for some reason but did not change it back. Regardless of why the screen resolution is lower, the result is blurry text that can significantly increase eye fatigue when reading on a PC screen for a long period of time. For LCD displays, much of the blurriness is caused by the fact that they are made up of fixed pixels. In non-native resolution settings, this means that the system must render fractional pixels across fixed units, causing a blurred effect. Another reason for the relative blurriness is that when the display is not set to native resolution, we can’t properly take advantage of our ClearType text rendering technology , which most people (though not all) prefer. It is interesting to note that the loss of fidelity due to changing screen resolution is less pronounced on a CRT display than on an LCD display largely because CRTs don’t have fixed pixels the way that LCDs do. However, because of the advantages in cost and size, and the popularity of the laptop PC, LCD displays are fast gaining market share in the installed base. Another problem with running in a non-native screen resolution is that many users inadvertently configure the display to a non-native aspect ratio as well. This results in an image that is both blurry and skewed! As you can imagine, this further exacerbates the issues with eye strain.
Looking beyond text, in these scenarios the resulting fidelity for media is significantly reduced as well. With the configuration that many users have, even if their hardware is capable, they are not able to see native “high def” 720p or 1080p TV content, which corresponds to 1280x720 and 1920x1080 screen resolutions respectively. The PC monitor has traditionally been the “high definition” display device, but without addressing this problem we would be at risk of trailing the TV industry in this distinction. While it is true that only about 10% of users have a truly 1080p capable PC screen today, as these displays continue to come down in price the installed base is likely to continue to grow. And you can bet that there will be another wave of even higher fidelity content in the future which users will want to take advantage of. As an example, when displays get to 400 DPI they will be almost indistinguishable from looking at printed text on paper. Even the current generation of eBook readers with a DPI of ~170 look very much like a piece of paper behind a piece of glass
From this we see that there is a real end user benefit to tap into here. It turns out that there is existing infrastructure in Windows called “High DPI” which can be used to address this. High DPI is not a new feature for Windows 7, but it was not until Vista that the OS user-interface made significant investments in support for high DPI (beyond the infrastructure present earlier). To try this out in Vista, rt. Click desktop -> personalize and select “Adjust Font Size (DPI)” from the left hand column. Our thinking for Windows 7 was that if we enable high DPI out of the box on capable displays, we will enable users to have a full-fidelity experience and also significantly reduce eye strain for on-screen reading. There is even infrastructure available to us to detect a display’s native DPI so we can do a better job of configuring default settings out of the box. However, doing this will also open up the door to expose some issues with applications which may not be fully compatible with high DPI configurations.
One of the issues is that for GDI applications to be DPI aware, the developer must write code to scale the window frame, text size, graphical buttons, and layout to match the scaling factor specified by the DPI setting. Applications which do not do this may have some issues. Most of these issues are minor, such as mismatched font sizes, or minor layout artifacts, but some applications have major issues when run at high DPI settings.
There are some mitigations that we can do in Windows, such as automatic scaling for applications which are not declared DPI aware (see Greg Schechter’s blog on the subject), but even these mitigations have problems. In the case of automatic scaling, applications which are not DPI aware are automatically scaled by the window manager. The text size matches the user preference, but it also introduces a blurry effect for that application’s window as a result. For people who can’t read the small text without the scaling, this is a necessary feature to make the high DPI configuration useful. However, other customers may only be using applications that scale well at high DPI or may be less impacted by mismatched text sizes and may find the resulting blurry effect caused by automatic scaling to be a worse option. Without a way for the OS to detect whether an application is DPI aware on not, we have to pick a default option. It always comes back to the question of weighing the benefits and looking at the tradeoffs. In the long term, the solution is to make sure that applications know how to be resolution independent and are able to scale to fit the desired user preference, which requires support in both our tools and documentation. The challenge for a platform is to figure out how to get there over time and how to produce the best possible experience during the transition.
Short term vs. long term customer satisfaction
Using the model of high definition TV, we can see that in the long term it is desirable to have a high fidelity experience. The only problem is that even though the high DPI infrastructure has been around for several windows releases (in fact there is an MSDN article dated 2001 on making applications DPI aware), we were not sure how many applications are actually tested in these configurations. So we were faced with an un-quantified potential short term negative customer impact caused by enabling this feature more broadly. The first thing we did is to quantify the exposure. We did this by performing a test pass with over 1,000 applications in our app compat lab to see how they behave at high DPI settings. The results we found are shown below, which shows the distribution of issues for these 1000 applications.
One quick thing, when we say “bug” we mean any time software behaves in a manner inconsistent with expectations—so it can be anything from cosmetic to a crash. We categorize the severity of these bugs on a scale from 1 to 4, where Sev 1 is a really bad issue (such as a crash and/or loss of data or functionality) and Sev 4 is an issue which is quite subtle and/or very difficult to reproduce.
One quick thing, when we say “bug” we mean any time software behaves in a manner inconsistent with expectations—so it can be anything from cosmetic to a crash. We categorize the severity of these bugs on a scale from 1 to 4, where Sev 1 is a really bad issue (such as a crash and/or loss of data or functionality) and Sev 4 is an issue which is quite subtle and/or very difficult to reproduce.
It turns out that most applications perform well at high DPI, and very few applications have major loss of functionality. Of course, it is not the ones that work well which we need to worry about. And if 1% of applications have major issues at high DPI, that could be a significant number. So we took a look at the bugs and put them into categories corresponding to the issue types found. Here is what we came up with:
What we found was that one of the most significant issues was with clipped UI. Looking into this deeper, it became apparent that most of these cases were in configurations where the effective screen resolution would be quite low (800x600 or lower). Based on this, we were able to design the configuration UI in such a way that we minimized the number of cases where users would configure such a low effective resolution. One by one we looked at the categories of issues and when possible, we came up with mitigations for each bucket. Of course, the best mitigation is prevention and so High DPI is a major focus for our developer engagement stories for PDC, WinHEC, and other venues coming up.
Aggregate vs. individual user data
One thing for us to look at is how many users are taking advantage of high DPI today (Vista/XP). Based on the data we have, only a very small percentage of users are currently enabling the high DPI feature. This could easily be interpreted as a clear end user message that they don’t care about this feature or have a need for this feature. An alternate explanation could be that the lack of adoption is largely because XP and Vista had only limited shell support for high DPI, and the version of IE which shipped on those platforms had significant issues with displaying mismatched font sizes and poorly scaled web pages. Also, we do know anecdotally that there are users who love this feature and have used it even before Vista. Once again, we have to make an interpretation of the data and it is not always crystal clear.
Timing: is this the right feature for the market in this point in time?
Fortunately, we don’t have a “chicken and egg” problem. The hardware is already out in the field and in the market, so it is just a matter of the OS taking advantage of it. From a software perspective, most of the top software applications are DPI aware (including browsers with improved zooming, such as IE 8), but there remain a number of applications which may not behave well at high DPI. Another key piece of data is that display resolution for LCD panels is reaching the maximum at standard DPI. For these displays, there is no reason to go beyond 1900x1200 without OS support for high DPI because the text would be too small for anyone to read. Furthermore, this resolution is already capable of playing the highest fidelity video (1080p) as well as 2 megapixel photos. The combination of existing hardware in the field, future opportunity to unlock better experiences, and the fact that the hardware is now blocked on the OS and the software speak to this being the right timing.
Looking at customer data helps us identify ways to improve the Windows experience. In this case, we saw clearly that we had an opportunity to help users easily configure their display such that they would enjoy a high fidelity experience for media as well as crisp text rendered at an appropriate size. With that said, anytime we invest in a feature that can potentially impact the ecosystem of Windows applications we want to be careful about bringing forward your investments in software. We also want to make sure that we engage our community of ISVs early and deeply so they can take advantage of the platform work we have done to seamlessly deliver those benefits to their customers. In the meantime, the internal testing we did and the data that we gathered was critically important to helping us make informed decisions along the way. High DPI is a good example of the need for the whole ecosystem to participate in a solution and how we can use the customer data in the field, along with internal testing, to determine the issues people are seeing and to help us select the best course of action.
Introducing Christina Storm who is a program manager on the Windows Customer Engineering feature team working on telemetry.
In a previous article Steven has introduced the Windows 7 Feature Teams. I am a program manager working on telemetry on the Windows Customer Engineering team. Our team delivers the Windows Feedback Program, one of several feedback programs in place today that allow us to work directly with customers and make them part of our engineering process.
The Windows Feedback Program (WFP) has been active for several years during the Windows XP and Windows Vista product cycles, and we are currently ramping up to get all aspects of this program ready for Windows 7. At the core of this program is a large research panel of customers who sign up via our website http://wfp.microsoft.com during open enrollment. Customers choose to be part of a survey program, an automated feedback program or both. They then complete a 20-minute profiling survey, which later allows us to look at their feedback based on their profile. We have customers spanning a wide spectrum of computer knowledge in our program, and we are constantly working on balancing the panel to staff up underrepresented groups. The majority of customers who are spontaneously willing to participate in a feedback program like ours are generally enthusiastic about technology. They are early adopters of consumer electronics, digital devices and new versions of software. In contrast, customers who see the PC as a tool to get a job done tend to be a bit more reluctant to join. And we also need more female participants!
Customers who participate in the automated feedback program install a data collection tool developed by the Windows Telemetry Team. The privacy agreement of this program describes the data collections our tool performs. Here are a few examples:
From the collected data we create reports that are consumed by a large number of Windows feature teams as well as planners and user researchers. This chart below shows the answer to the following question: What is the most common file type that customers who participate in our program store on their PCs and what are the most popular storage locations?
The results help us both with planning for handling the volumes of data customers store on their PCs as well as mimicking real-life scenarios in our test labs by setting up PCs with similar file numbers and file sizes and distribution of files on the PCs.
These data collections furthermore allow us to create reports based on profiled panelists. The above chart may look different if we created it based on data delivered only by developers and then compare it to data delivered only by gamers, just to name a couple of different profiles that participate in our program. The Windows knowledge level sometimes makes a difference, too. Therefore it is very important to us that customers participate in this program who consider themselves Windows experts as well as customers who don’t enjoy spending too much time with the PC, who just see the PC as a tool to get things done. Based on the data, we may decide to optimize certain functionality for a particular profile.
In general, we utilize this data to better understand what to improve in the next version of Windows. Let’s take a look at how the representative sample has their monitors configured. First what resolutions do customers run with on their PCs? The following table lists typical resolutions and the distribution based on the Windows Customer Experience Improvement Program, which samples all opt-in PCs (Note the numbers do not add to 100% because not every single resolution is included):
One thing you might notice is that about 10% of consumers are running with HD or greater resolution. In some of the comments, people were asking if our data represented the “top” or “power users”. Given this sample size and the number of folks with industry leading resolution I think it is reasonable to conclude that we adequately represent this and all segments. This sample is a large sample (those that opt-in) of an extremely large dataset (all Windows customers) so is statistically relevant for segmented studies,
We have found that a large percentage of our program participants lower their display resolution from the highest usable for their display. Looking at the data coming from the Windows Customer Experience Improvement Program to compare to, and noticed a similar trend: over 50% of customers with 1600x1200 screen resolution displays are adjusting their resolution down to 1024x768, likely because they find it uncomfortable to read the tiny text on high resolution displays. The negative effect of this resolution change is the loss of fidelity to the point where reading text in editors and web browsers is difficult. High definition video content also won’t be able to render properly.
Here is the data just for customers with displays capable of 1600x1200:
In a future blog post, one of the program managers from the Windows Desktop Graphics team is going to describe what we have done with that information to improve display quality and reading comfort in Windows 7.
We also frequently use our data to select appropriate participants for a survey. A researcher may be interested in sending out an online survey only to active users of virtual machine applications. We would first determine that group of users by looking at our “application usage” data and then create the list of participants for the researcher. Sometimes we combine automatically collected data with survey responses to analyze the relationship between a customer’s overall satisfaction and their PC configuration.
At the current point in time, 50% of our panel participants are using Windows XP and 50% are using Windows Vista. We are currently not offering open enrollment. If you are interested in being invited to this program, please send an email to firstname.lastname@example.org indicating “Notify me for enrollment” in the subject line. If you’d like to add a bit of information about yourself, including your Windows knowledge level, that would be much appreciated! We will add you to our request queue and make our best effort to invite you when we have capacity.
When we release the Windows 7 beta we will also be collecting feedback from this panel and asking for participation from a set of Windows 7 beta users. Our current plans call for signing up for the beta to happen in the standard Microsoft manner on http://connect.microsoft.com. Stay tuned!
-- Christina Storm
As you can imagine, our team is quite busy working through this next phase of Windows 7. We definitely appreciate the millions of downloads and installs of the Windows 7 RC. Things are going as we expect at this point. On a personal note, I wanted to thank all the folks who have been sending me mail. I’ve received a lot of kind words and support regarding the RC and quite a few people saying “hurry up and just release it”. We outlined the steps we’re taking for this next milestone and aren’t going to rush things. We’ve got a lot of work for sure! Not that I’m counting, but I just crossed over 3,000 emails sent via the contact link in this blog. While I haven’t answered all of them, I’ve done the best I can, and appreciate each and every exchange.
Windows 7 includes a set of features for safeguarding your PC when used by children. This post is by Vladimir Rovinsky, a program manager on our Safety Team, who details the features in Windows 7 specifically around Parental Controls. This work is in addition to the safety of the OS itself and of course the features built into Internet Explorer to provide safety and security while browsing. You might also want to check out Windows Live Family Safety which is part of Windows Live Essentials (http://download.live.com) which provides even more for safety and parental controls. --Steven
Today, children are exposed to digital hazards more easily than any time in the past. Especially with the help of powerful search tools, convenient social networking applications, low cost tools and services for publishing videos and photographs, the web is awash with content that’s inappropriate for children, and full of people that parents want to bar from contacting their children.
These digital hazards are accessible to children through a variety of applications, including web browsers, instant messaging applications, media players, games, and email applications. Many of these applications have attempted to offer parental control features. However, they offer this functionality through variety of user interfaces, locations and include varied terminology. The duplication and inconsistency of parental control settings management can make it difficult for parents to maintain the correct settings across multiple applications.
Windows Vista Parental Controls provided a framework to solve these problems by offering:
To get a quick demo of Windows Vista Parental Controls in action, check out this video.
For more information about developing software for Windows Vista Parental Controls, see Using Parental Controls APIs.
Responding to customer feedback and evolving nature of the web and challenges it poses to the parents, we strive to provide families with flexible and effective safety features. Our efforts for the Windows 7 release of Parental Controls were focused on the following objectives:
1. Further developing the extensibility of the Parental Controls platform to enable third-party developers to create richer Parental Control capabilities that integrate well with Windows 7 Parental Controls.
The Windows 7 Parental Controls platform was modified to allow multiple independent providers of Parental Controls functionality to be installed on the system and augment or fully replace the parental controls provided by Windows 7. Windows Vista allowed partial replacement of Windows Parental Controls; the web filter was replaceable. In Windows 7, in addition to the web filter components, the entire Windows 7 Parental Controls user interface can be replaced by third-party providers. The underlying enforcement of the offline restrictions will still be performed by Windows Parental Controls platform. Allowing a third party provider to replace the entire Windows Parental Controls user interface creates a consistent user experience that seamlessly combines existing Parental Controls functionality with the new ones introduced by the third-party provider.
The Windows Control Panel Parental Controls screen still remains the central location and launching point on Windows 7 for Parental Controls functionality regardless of whether it is provided by default (system) or by a third-party provider.
2. Removal of web content restrictions and activity viewing functionality from default (system) Parental controls provider and reliance on Windows Live or third-party providers for these capabilities.
The web is changing much faster than we can update the Windows operating system. For example, when Vista was released Social Networking was barely known. Now it has a thriving web presence. We need to keep web focused parental controls up with innovation. Because of this, we have moved them into Windows Live.
Web filtering and activity viewing capabilities can be more efficiently provided by Windows Live or a third-party solution that implement web based delivery of this functionality. For instance, Microsoft’s Windows Live Family Safety free application provides web content filtering, file downloads restrictions, and activity monitoring. It also provides online contact restrictions for children using Windows Live online applications (Windows Live Hotmail, Windows Live Messenger, etc).
You can learn more about Windows Live Family Safety solution here.
More information about Windows 7 changes to the Parental Controls platform can be found here.
Elements new to Windows 7 Parental controls top-level screen can be seen on the following screen shot:
Figure 1 Windows 7 Parental Controls screen
Additional control providers can still rely on the default’s (system) provider UI for the configuration of in-box offline restrictions. If a provider chooses to do so, the User Controls screen can be presented to configure a user’s Parental Controls settings.
If an additional provider is selected and configured, the following new user interface elements are shown on the Windows 7 User Controls screen:
Figure 2 Windows 7 User Controls screen. Additional controls provider is installed and configured.
If a Windows Vista PC which has parentally managed user accounts with enabled web filtering restrictions is upgraded to Windows 7, parents (administrators) are warned during the upgrade as well as when opening the Windows 7 Parental Controls screen, that web filtering and activity reporting functionality is not part of Windows 7 Parental Controls.
Figure 3 Windows 7 Parental Controls screen. Some users have web filtering restrictions. No additional provider is installed.
Windows Vista Parental Controls settings (including web filtering and activity logs information) are preserved unchanged when upgrading from Windows Vista to Windows 7. Although web filtering settings and activity logs information are not used by Windows 7 Parental controls, their preservation allows third-party provider to honor these settings.
As you start using Windows 7, we hope these changes to Parental Controls capabilities will make you feel more confident and in control of how your family members are using computers and experiencing the web.
This post continues the discussion of Compatibility testing from our test team. --Steven
In the previous blog post "Application Compatibility Testing for Windows 7" we talked about the importance of Application Compatibility and work we are doing to engineer this in Windows 7. In this post we will examine the challenge that emerges as we consider the world wide audience that Windows serves.
This blog post will cover the following areas:
For Windows 7 we have made significant investment in application compatibility, ensuring applications that worked on Vista, continue to work on Windows 7 and we’ve also rescued some applications that were broken in Vista to work on Windows 7 (more on that later). As we’ve talked about, there are some applications that are OS version specific by design (utilities, firewalls, security, etc.) and those are not included in this discussion.
One of the biggest challenges in International Application Compatibility is what applications we test, the scale of testing, and what it means for us to say that an application “works”. For Windows 7 we are testing over 1200 applications across 25 specific markets. We have improved our coverage over Vista by adding over 300 more international applications.
We look at applications in 3 buckets.
Categories 1 & 2 are pretty straightforward. There are a known set of key applications and scenarios used around the world and we must ensure these applications function in Windows 7. Category #3 is where there is some complexity.
The applications list we build for 3rd Party Local Applications is built using a number of methods. First, we build on the list of applications we have used in previous versions Windows (XP/Vista, etc). If it worked on Vista, it must work on Windows 7.
Next we work with our teams in markets around the world to rank top applications in particular markets. It is amazing to see the diversity in application use around the world. The application testing list is based on a combination of market data where it is available, individual knowledge of markets, culture, revenue, usage and even sometimes just “word on the street”. The cultural knowledge in these markets is probably most critical to our success. For example, casual gaming in Korea is hugely popular and we need to ensure our Windows 7 testing accounts for this.
Our goal in selecting applications is to test as many applications as we can that will expose the most issues across different scenarios and markets.
These scenarios include:
Once we build the list of applications we need to test the next process is acquiring them. We acquire applications in a variety of ways but many times we have to buy an application from a retail store just as any end user would. Other methods we use to acquire applications include downloading full featured trial versions, purchasing software, and working with ISVs to acquire their applications to ensure compatibility.
Testing applications means more than just installing them and making sure they launch. Every application gets a unique test plan written for it to cover as much functionality as we can. We write test cases to cover primary and secondary application functions – for our word processing example this would include opening a file, typing a letter, adjusting formatting, save, and print, emailing a copy to someone, etc. These applications go through 6 or more test passes during the product cycle.
Now, we can’t test every piece of every application and we do run into some interesting challenges when we focus on a worldwide audience. Many applications depend on location specific information (meaning if you aren’t testing the application in that location – you aren’t likely to have the information needed). Examples include Brazilian citizen’s CPF ID, or Brazilian personal number of identification which would be required to test something like tax preparation software. We run into similar problems with SMS applications requiring active local mobile phone accounts.
Along with the core tenet of ensuring that any application that worked on Windows Vista also work on Windows 7 we have a stretch goal to “raise the bar” and make applications work on Windows 7 that never worked on Windows Vista. For Windows 7, we have some good news early in the development cycle. So far we have made over 30 applications that were “broken” on Vista work on Windows 7. This means that Windows 7 will have higher application compatibility than Windows Vista. We are continuing to push this number up. Below is a table of the # of applications by language that we have made to work on Windows 7 but didn’t’ work on Vista.
Asure Purchase/Sale/Stock Master 2008
Cyberlink DVD Suite v6
Asure Accounting Master 2008
Haufe Personal Office Professional - Haufe Formular-Manager
Compedia Timmy in English World
Compedia Moomins: The Search for the Ruby
Compedia The Puzzling Time Quest
Finson Costo del Lavoro Italian v2
Finson Falco 6
Finson Progetto Condominio
Finson Contintasca 7
Kenchako Adventure 9.0
WZ Editor 5.0
Overland LOKI: with Japanese Manual
WF-Fakturka dla Windows
Nahlik eTeacher 5
Mexico Federal Taxes Simplified SAT: Individual Taxes
IKEA Home Kitchen Planner
Along with ensuring these applications work on Windows 7 we have taken an extra step for our existing Vista customers. Of the applications outlined in the above table, 27 of the fixes we made have been back ported to Windows Vista for possible inclusion in future updates. We really wanted to raise the bar for application compatibility and go beyond just looking at Vista as the baseline.
There is a lot of information here and hopefully gives you some insight into what it means for us to make the application experience (application compatibility) on Windows 7 as high as possible for users around the world. We started out with a goal of making sure if an application worked on Windows Vista it should work on Windows 7. We have taken that further by bringing applications that never worked on Vista to work on Windows 7 and even future updates to Vista.
This post is from Michael Bernstein, a development lead on the User Interface Platform team where he focuses on accessibility. Accessibility is the term we apply to the APIs and features that enable Windows to be used, to be accessible, by as many people as possible so that, regardless of physical or cognitive abilities, everyone has the ability to access the functions of Windows. To enable this, Windows includes both built-in accessibility utilities as well as APIs used by third party assistive technology aids and by application developers to make sure their software is also accessible. This is a topic that is extremely important to Microsoft and one that is a key tenet in the engineering of Windows 7. Microsoft also has a corporate-wide group dedicated to making sure that PCs are easier to see, hear, and use. You can read more about Microsoft’s accessibility initiatives on http://www.microsoft.com/enable/. --Steven
Hi, I’m the development lead for Accessibility and Speech Recognition experiences in Windows 7, and I wanted to write about how we thought about Accessibility in Windows 7.
We wanted to make Windows 7 the most accessible operating system that Microsoft has ever produced. It became clear as we planned this release, however, that the notion of Accessibility is not as simple as it may appear. It is tempting to think about Accessibility like Security: either you have a known failure, or your system is believed to be secure/accessible. This definition turns out to be limited, though. How do you deal with the fact that the needs of customers who are blind are very different from the needs of customers who are deaf? The needs of customers who are blind are even different from those of customers with reduced vision: a magnification tool is useless for one group and crucial for the other. And what do we make of cases where something is technically accessible but practically frustrating, like a common user scenario that takes 36 keystrokes to execute? Clearly, Accessibility wasn’t going to boil down to a simple yes/no question. It is really more like a particular kind of usability, but usability for a specific set of audiences with individual needs.
Since the questions we were asking were complex, the answers ended up being complex, too. We chose a four-part strategy to improve Accessibility in Windows 7.
In Windows Vista, Microsoft delivered a new core component for Accessibility called UI Automation. UI Automation enables a user’s assistive technology (AT) to programmatically drive the UI of an application, and allows applications to expose their accessible functionality in a richer way than was possible in previous versions of Windows. More questions can be asked about a piece of UI, and that UI can be manipulated in richer ways. UI Automation also introduced the idea of Control Patterns: any given piece of UI can decide how it should be controlled. Buttons expose the Invoke pattern, indicating that they can be pushed; Combo Boxes expose ExpandCollapse, indicating that they can be opened and closed. We let different controls be different, instead of trying to force them all into the same mold. All this was introduced in Windows Vista and adoption is still ongoing.
In Windows 7, we invested in improving the performance of the UI Automation system and created a new, native-code API for UI Automation to make sure that it can be used effectively by a wide range of assistive technology software. Now applications written in C++, as well as those written using the .NET Framework, can take advantage of UI Automation.
We also did a bunch of work to make sure that the UI Automation system was integrated even more closely with the legacy Microsoft Active Accessibility (MSAA) system and developed new bridging techniques between the best of the new and the old technologies. UI Automation Clients can read Accessibility information from MSAA applications, and vice versa, to ensure maximum Accessibility regardless of which accessibility API an application used originally. Since the UI Automation and MSAA systems cooperate closely in many scenarios, we decided to name the combination of the two, calling it the Windows Automation API. This architecture forms the foundation for the rest of our Accessibility effort, and we’re pleased to have this Accessibility foundation Windows 7.
We also improved the Accessibility utilities that we include in the box with Windows. Microsoft works closely with many different AT software companies who deliver software to make Windows more accessible to customers with disabilities, but we also include a set of utilities to make sure that our customers’ early experiences are accessible, even before installing any other software. We decided to enhance two of those utilities in Windows 7: the On-Screen Keyboard and the Magnifier.
The most noticeable change to the On-Screen Keyboard is the improved look and feel, but there are also more subtle enhancements. The appearance of this utility had not changed since Windows XP; our customers were also asking for it to be resizable. We addressed both of these by working closely with Tablet developers to share a common code base between the Tablet Soft Keyboard and the On-Screen Keyboard. Both keyboards now have an attractive appearance that is in tune with Windows 7 and both are now resizable. The keyboards still are distinct, though, because customers use them differently: Tablet users may want to switch dynamically between handwriting and typing, whereas On-Screen Keyboard users may need modes where they can hover or scan to keys, if they have disabilities that prevent them from clicking. Along these lines, we also added basic text prediction to help customers with disabilities enter text more quickly. If you have ever tried typing with an on-screen keyboard, you can appreciate how significantly text prediction can improve text entry speed.
The Magnifier came in for a deeper overhaul. The Magnifier in Windows Vista and Windows XP was not an intuitive experience: when you pointed at part of the screen, the magnified content appeared in a separate window, usually docked at top of the screen. You had to point at one place and look at another. We considered two basic solutions to this problem: you could zoom into the entire screen or you could make the magnified area follow the pointer while leaving the rest of the screen the same. These became our two primary modes for the Windows 7 Magnifier: Full-screen mode and Lens mode.
Full-screen mode is great when you want to increase the size of everything on the screen at once. As you move the mouse or keyboard focus around the middle of the screen, the view stays still; if you move towards the edge, the Magnifier scrolls the view to keep up. One downside of this mode is that you can lose track of your context. To address that usability issue, we added a context animation that zooms out to show you where your work area is relative to the whole screen, and then zooms back in.
Lens mode, on the other hand, is nice when you just want to zoom in on one particular thing. In this mode, the lens centers on the mouse pointer, which feels much like using a magnifying glass. You can re-size the lens to be very wide and short, which can be nice if you are reading a document and want to magnify it line by line. We based our design on the popular Microsoft IntelliPoint magnifier, a design you can now enjoy with any mouse.
We also addressed customer feedback about the Magnifier window taking up too much space on the screen. We moved the most commonly used controls like zoom in/out to a small toolbar, which fades out to a semi-transparent watermark when you aren’t using it. The remaining options are available in an Options dialog when you need them. Last, we gave almost everything a keyboard shortcut, so if you really don’t want to see the UI, you don’t have to use it. Win-+ will zoom you in any time you are using Windows 7.
These tools directly improve Accessibility for customers with low vision and dexterity disabilities. It should be obvious, but making the PC easier to see or interact with benefits everyone and so these two examples also show the broad appeal of AT tools – at the PDC we showed both the On-Screen Keyboard and the Magnifier and I think it is fair to see everyone saw the benefit of using these tools themselves, regardless of abilities.
Windows APIs cannot provide Accessibility all by themselves; it is vital for Windows-based applications to do their part in providing Accessibility data for AT programs to use. For example, a screen reader may sound excellent, but if it can’t read your favorite web browser, what good is that? Assistive tools like screen readers and magnifiers are clients of the Accessibility system, while the applications that you want to use, like web browsers and word processors, are providers. It takes both to make the whole experience accessible--you need both a high-quality client and a well-written provider to have a good Accessible experience. There are more providers in the software ecosystem, so it is hard for us to work one-on-one with every provider to make sure they are well-written.
To address this challenge, our team developed the UI Accessibility Checker (AccChecker for short) and UI Automation Verify (UIA Verify) utilities, which can scan an application (a provider, really) and report on common Accessibility problems. Software developers can use AccChecker and UIA Verify to detect problems in their provider code before a customer ever uses it. Quality assurance engineers can use them to verify the quality of their firm’s work. We believe this is so important that we released AccChecker and UIA Verify as open-source software to make it available to the widest possible audience. If you are not a programmer, you may never use these utilities directly, but you may well benefit from the bugs they helped to eliminate before they ever reached you.
To make sure that Windows features themselves were good providers, we borrowed an idea from the Software Development Lifecycle, risk assessment. Before a line of code was written, each planned Windows 7 feature was rated on its Accessibility risk. Features that use more basic, off-the-shelf common controls are usually more accessible because Windows provides built-in providers for off-the-shelf components; features that do fancy, custom drawing have more work to do. This planning process made each team aware of how much accessibility risk it was taking on, so that they could plan appropriately. Once the features were all rated, the list was sorted by risk so that our team could reach out to teams with high-risk features and make sure that they had the resources and tools they needed to make their feature properly accessible. We also ensured that they received more hands-on testing and validation. As a result, most Windows features are more accessible than they have been in previous releases, making for a better overall customer experience.
To wrap up, we've emphasized Accessibility in engineering Windows 7. We’ve made good progress on improving the core architecture for Accessibility and enhancing the included tools like On-Screen Keyboard and Magnifier. The AccChecker and UIA Verify tools have made it much easier to validate applications to ensure that they will be compatible with current assistive tools as well as future tools based on the Windows Automation API. Our approach to Accessibility for the features and providers in Windows itself has become more thorough, consistent and integrated, thanks to the hard work of hundreds of engineers across the company. We’re proud of what we have accomplished in Windows 7 and hope that it will help customers with disabilities to realize their full potential and have a more enjoyable experience with Windows.
As the community participates in the E7 blog, we want to offer some guidelines on how we are going handle comments in general. Our primary goal is for this to be a place for open discussion about Windows Engineering, so we don’t want to have lots of overhead and process.
We love comments. We know everyone on the Windows team will be watching for comments and is looking forward to the dialog. We will work to make sure that Microsoft employees represents themselves as such, especially if they work on Windows.
Things we want to see in comments:
Things that will get comments edited/deleted:
We hope these rules will keep the discussion lively and on topic.
Steven and Jon
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.
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.
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.
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:
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 :-)