Skip to content

Building Windows 8 (dari

27 August 2011

Our previous post about the new copy experience in Windows 8 generated a lot of questions and comments about the new “Choose Files” dialog for resolving file name collisions. Based on the level of interest, we thought it would be fun to share some of the design iterations and our usability testing that led us to this design.

In the implemented design, there are two levels of control when acting on file name collisions (or “conflicts”).

  • The primary experience is a simplified, one-click, bulk management of all conflicts, offering “Replace all” or “Skip all.” We call this the “Simple Conflict Resolution dialog.”
  • There is also an option to enter the secondary experience which offers more information and more fine-grained control. This is the “Detailed Conflict Resolution dialog.”

Figure 1 - Final dialogs

Windows 7 and before

Resolving file name collisions is an inherently tricky task, as it involves making a meaningful choice between two very similar things.

Here’s how we did this back in Windows 3.1:

Figure 2 - Windows 3.1 Conflict

We’d certainly made some progress by the time we got to this in Windows 7:

Figure 3 - Windows 7 conflict resolution dialog

In Windows 7, there’s a lot of information to aid the choice, and more options about what action to take. For Windows 8, we thought we could improve this even further, so it’s easier for you to make the right decisions more efficiently, and get your file transfer tasks completed faster. As we mentioned, the feedback and support calls on the existing dialog were clear—folks were having a hard time finding the information needed to make an informed choice in a fairly complex dialog. Even with the amount of work we do, sometimes it takes quite a while to surface something that isn’t optimal. Keep in mind millions of people used pre-release Windows 7 and this was not a big topic of discussion on our forums (not to say that it didn’t come up, but it was not a broadly raised topic).

Improving on the Windows 7 experience

First, we looked at ways to keep the experience basically the same, but to incrementally improve it by optimizing for the key information that is necessary for the decision.

Figure 4 - Early concepts for single-file conflict resolution

These designs introduced some concepts that really stuck around:

  • Getting rid of unnecessary labels (like “Date modified:”) and obvious explanatory text enabled us to present the important details at a glance.
  • Metadata adjectives were emphasized. Rather than requiring users to compare values like file size, using words like “Larger” gave users the right summary.
  • Smart defaults were pre-selected, reducing the work for users.

Fast and fluid: better bulk management of conflicts

In Windows 8, we want you to be able to get stuff done more quickly and efficiently—”fast and fluid” are key design words around Windows 8 for all of our designs (for touch, mouse/keyboard or both together). The next major design iteration looked at ways that we could follow on from the cohesive copy progress experience, bring queued-up conflicts together into a single dialog, and provide you with the ability to manage them in a more streamlined way.

The idea of optimizing for the “Replace all” or “Skip all” choice was introduced. Most of the time, you know exactly what you’re copying and why it is conflicting, and you can make a simple choice about what action to take.

Figure 5 - Adding bulk management

For cases where you need more information or finer-grained control, we decided to disclose information in “tiers” of greater detail.

We started with two tiers:

Figure 6 - First two-tier

Then we tried three-tiers:

Figure 7 - Three-tier

And ended up back at one-tier:

Figure 8 - One-tier

This design offers many positive attributes. It provides a lot of information. Since clicking on the headers selects everything in a column, it provides real power for managing conflicts. But it was a very complex piece of UI to be presenting as the initial experience.

Instead, we combined the best of these options into the following:

Figure 9 - One dialog two-tier

Simple and detailed conflict resolution

It was clear that this design was heading toward a balanced combination of simplicity and power that would suit user patterns.

Unfortunately, we identified a real challenge with this design: when you select “Let me pick,” the result is confusing and overly complex because the simpler and advanced options are both available. This led us to a design where the “Simple Conflict Resolution dialog” and the “Detailed Conflict Resolution dialog” were discrete experiences.

Figure 10 - Basic structure

With this decision, our basic structure was in place.


In preparation for testing with users, we iterated on the design.

  • We cleared up the confusion caused by a single thumbnail.
  • We made the source and destination (and their columns) more apparent.
  • Our User Assistance team (the experts in authoring text we use in the product, assistance, and the web) helped us out with better text.

Figure 11 - Pre-test

It’s interesting to see the similarities between the Simple Conflict Resolution dialog and some of the earliest designs for dealing with single file conflicts. It’s also interesting how similar they both are to the final design for the dialog.

First round of usability research

In our usability tests our researchers find a diverse set of subjects who don’t work at Microsoft and represent a range of different skill levels and experiences. We show them the software and ask them to complete a set of tasks. By listening as they describe their thought process, using eye-tracking to watch how they see the UI and measuring successful task completion, we gain valuable insights into what works (or not) about a design.

It is super important to understand that usability tests are one tool we use. Anyone who has ever used this tool knows that you have to be both an expert in the domain and also an expert at designing tests themselves as observer bias and test construction can easily lead you to a false sense of security or efforts to optimize an inherently flawed solution. To help us in that regard, our tests are designed by objective researchers who understand the limits of what can be tested and also make sure that the conclusions drawn from the test match what the test was meant to measure. Ultimately, design choices require the use of many different inputs both qualitative and quantitative as well as experience and intuition.

We knew that we’d learn a lot in our first round of usability tests and make many changes, so we used the RITE method as our protocol. Most usability studies test the same UI with all users, but with RITE, we make changes continuously between participants, based on what we learn. (We were testing with PowerPoint slides at this point, so change was cheap.)

We didn’t end up needing to make many changes to the Simple Conflict Resolution dialog as it tested well, but we tested lots of different things for the Detailed Conflict Resolution dialog:

Figure 12 - Dialogs tested for first RITE study

Our key lessons:

  • Check boxes are necessary. As much as we preferred the cleaner no-checkbox look, it simply didn’t test well. Users didn’t know what to do when presented with the UI. Check boxes were much more effective in providing appropriate cues for selection. We made sure to retain a large click-target area, so users can click on the check box, thumbnail, or the text to select a file.

Figure 13 - Click target

Click target area for file selection

  • Mixing the adjectives (e.g. “newer,” “larger”) and the metadata was confusing. Users interpreted them as two different concepts. The adjectives were particularly problematic – people thought they were titles, or described the file location (for example, “older” was interpreted to mean the files in the destination because they were present prior to the copy.)
  • Columns needed to be more distinct. At first glance, it looked like the Tiles view in Explorer, rather than a table.

More refinement

There was no simple solution to the adjective and column issues, so that led to more design explorations:

Figure 14 - Intra-test refinement

We really struggled with how best to define the hierarchy and importance of source/destination versus conflict rows. We tried vertical lines, which separated the source and destination too much. We ultimately landed on horizontal lines, combined with the file name as a header, to give the most prominence to the distinction between conflicts. The check boxes aided in distinguishing a choice between source and destination without interfering with this distinction.

Some of our earliest ideas were discarded at this point in the process:

  • No default choices. With conflicts scrolling off the page, defaults posed too much of a risk of data loss. No selection in a row results in the copy of that file being skipped, so nothing is lost.
  • No adjectives. We liked “Newer” and “Larger,” but they added confusion and users valued the concrete data.
    Instead, to help users make the choice, we chose a more subtle suggestion – the newer and larger metadata values are bold in the UI. This has proven to be surprisingly effective, without introducing new concepts or adding clutter.

More usability research

In our next round of usability tests, we were heading toward the final design, and tested fewer alternatives:

Figure 15 - Second usability test

The third option was the clear winner. The two-column view is the most efficient use of space and moves the check boxes close to the question. Date and time need to be on the same line because these are primarily a single value.

The Detailed Conflict Resolution dialog also offers the following features to help when even more information is required to make the decision:

  • Double-clicking the thumbnail opens the file.
  • Right-clicking the thumbnail opens the standard context menu.
  • The blue Source and Destination text are clickable, and open those locations in Explorer.
  • Hovering on the thumbnail or link shows a tooltip with the full file path.

Continuing to iterate

We’ve continued to conduct more studies and make minor changes since the initial research, but the core design has remained basically the same. It has been very encouraging to witness the ease with which users complete usability tasks. Resolving file name collisions is a tricky problem, but users are efficient and successful.

Figure 16 - Final design

Check out the video in our previous post on file management basics to see this design in action.

We love feedback and want to use it to make the best design we can, so we’ve been carefully reading all your comments, and look forward to you working with it in practice.

— Ben Truelove, Matt Duignan, Jon Class, and Ilana Smith

(If you missed them, several of our team members made comments on the previous post that addressed some of the questions raised: Alex, Matt, Jordi, Jon.)

Improving our file management basics: copy, move, rename, and delete

  • 545

We wanted to do an early Windows 8 post about one of the most used features, and one we have not improved substantially in a long time. With the increasing amount of local storage measured in terabytes, containing photos (in multiple formats and very large files), music, and video, these common operations are being taxed in new ways. These changes, along with consistent feedback about what we could improve, have inspired us to take a fresh look and redesign these operations. Of course this is just one feature among many, but we wanted to start with something we can all relate to. Alex Simons is a director of program management on our Windows engineering team and authored this post on the redesign of some Windows file management basics. (PS: A lot of folks asked about Building Windows 8 Video #1 — this is the user experience demo,  The numbering seems to be confusing so this will be our last numbered video.)–Steven

Copying, moving, renaming, and deleting are far and away the most heavily used features within Windows Explorer, representing 50% of total command usage (based on Windows 7 telemetry data). For Windows 8, we want to make sure that using these core file management commands, which we collectively refer to as “copy jobs,” is a great experience.

We know from telemetry data (which is based on hundreds of millions of individuals opting in to provide anonymous data about product usage), that although 50% of these jobs take less than 10 seconds to complete, many people are also doing much larger jobs, 20% of which take more than 2 minutes to complete. Prior versions of Windows Explorer can handle these kinds of jobs, but Explorer isn’t optimized for high-volume jobs or for executing multiple copy jobs concurrently.

Usability studies confirm what most of us know—there are some pretty cluttered and confusing parts of the Windows 7 copy experience. This is particularly true when people need to deal with files and folders that have the same file names, in what we call file name collisions. Lastly, our telemetry shows that 5.61% of copy jobs fail to complete for a variety of different reasons ranging from network interruptions to people just canceling the operation.

We clearly have an opportunity to make some improvements in the experience of high-volume copying, in dealing with file name collisions, and in assuring the successful completion of copy jobs.

Many of you reading this blog post come at this from a slightly different perspective. Like me, you might already have a third-party copy management tool that already addresses these high-volume scenarios. Our telemetry data shows that the most popular of these add-ons (such as TeraCopy, FastCopy, and Copy Handler) are running on fewer than .45% of Windows 7 PCs. While that might be a large absolute number given the size of the Windows 7 customer base, it still tells us that most people do not have a great tool for high-volume copy jobs.

We aren’t aiming to match the feature sets of these add-ons. We expect that there will be a vibrant market for third-party add-ons for a long time. Our focus is on improving the experience of the person who is doing high-volume copying with Explorer today, who would like more control, more insight into what’s going on while copying, and a cleaner, more streamlined experience.

In Windows 8, we have three main goals for our improvements to the copy experience:

  • One place to manage all copy jobs: Create one unified experience for managing and monitoring ongoing copy operations.
  • Clear and concise: Remove distractions and give people the key information they need.
  • User in control: Put people in control of their copy operations.

Based on these goals, we made four major improvements to the copy experience. Here is a short video demo of these improvements—but keep reading for a more detailed tour.

If you don’t see a video here or can’t play it, download it here: High quality MP4 | Low quality MP4

First, we’ve consolidated the copy experience. You can now review and control all the Explorer copy jobs currently executing in one combined UI. Windows 8 presents all pending copy jobs in this single dialog, saving you from having to navigate through multiple floating dialogs looking for the one you need.

Figure 1 - Consolidated copy (fewer details view)

Next, we’ve added the ability to pause, resume, and stop each copy operation currently underway. This gives you control over which copy jobs will complete first. You can also click any of the source or destination folders while the copy operation is taking place and open up those folders.

Figure 2 - Pause (fewer details view)

To support this new ability to prioritize and decide, we’ve added a detailed view with a real-time throughput graph. Now each copy job shows the speed of data transfer, the transfer rate trend, and how much data in left to transfer. While this is not designed for benchmarking, in many cases it can provide a quick and easy way to assess what is going on for a particular job.

Here you can see three copy jobs underway:

Figure 3 - Consolidated copy (more details view)

And here you can see how the speed of file transfer increases substantially when two of the copy jobs are paused:

Figure 4 - Pause (more details view)

We’re anticipating that many of you are going to want to know what we’ve done to improve the accuracy of the estimated time remaining for a copy to complete. (This has been the source of some pretty funny jokes over the years).

Estimating the time remaining to complete a copy is nearly impossible to do with any precision because there are many unpredictable and uncontrollable variables involved – for instance, how much network bandwidth will be available for the length of the copy job? Will your anti-virus software spin up and start scanning files? Will another application need to access the hard drive? Will the user start another copy job?

Rather than invest a lot of time coming up with a low confidence estimate that would be only slightly improved over the current one, we focused on presenting the information we were confident about in a useful and compelling way. This makes the most reliable information we have available to you so you can make more informed decisions.

Our last major set of improvements simplify and clean up the experience for resolving file name collisions, which we also refer to as “conflict resolution.” At this point we can admit that the current experience can be rather confusing. People don’t know which files are which, and they find it challenging to find the information they need to make a decision.

Figure 5 - Windows 7 conflict

Windows 7 Conflict Resolution dialog

Our new design is much more clear, concise, and efficient, providing a much more visible and actionable approach to conflict resolution. All the files from the source are on the left. All the files in the target location with file name collisions are on the right. The screen layout is easy to understand and shows you the critical information for all the collisions, front and center in one dialog.

Figure 6 - Conflict (more details)
The new Windows 8 Conflict Resolution dialog

If you need to know even more about the conflicting files, you can hover over the thumbnail image to see the file path or  double-click it to open it from here.

Finally, in addition to these big improvements, we’ve also done a thorough scrub and removed many of the confirmation dialogs that you’ve told us are annoying or feel redundant (i.e. “are you sure you want to move this file to the recycle bin?” or “are you sure you want to merge these folders?”) to create a quieter, less distracting experience.

All of this adds up to building a significantly improved copy experience, one that is unified, concise, and clear, and which puts you in control of your experience.

–Alex Simons

Building robust USB 3.0 support

  • 110

One of the important roles Windows plays as part of a broad ecosystem is developing support for new hardware. This is a pretty involved process and so for this post we wanted to take a look at supporting USB 3.0, something we know everyone is anxious to be using because of the improvements it brings. This is also our first video post – we aimed for “engineering” videos and not high production values but I think we make our point (note videos are embedded in HTML5 and available for download). If you’re like me when looking at the video, you might think that those file copy progress indicators are looking a bit dated…stay tuned. This post was authored by Dennis Flanagan, the Director of Program Management for the Devices and Networking group. –Steven

With throughput up to 10 times faster than USB 2.0 and improved power management that results in longer battery life, USB 3.0 introduces compelling reasons to improve the world’s most popular PC interface. By 2015, all new PCs are expected to offer USB 3.0 ports, and over 2 billion new “SuperSpeed” USB devices will be sold in that year alone.

 Figure 1 - USB 3.0 PC Market Forecast
In-Stat, June 2011

Figure 2 - USB Device Market Forecast, June 2011
In-Stat, June 2011

The decision to invest in USB 3.0 was an easy one to make, but doing so without compromising the existing USB ecosystem was a big challenge to overcome. Our design had to follow the revised 3.0 specification precisely in order to enable emerging USB 3.0 hardware. There are also billions of older USB devices that Windows must remain compatible with. How do you write a single piece of software to enable the latest technology on evolving hardware, while making sure it still works with 10 billion existing devices in homes and offices across the world?

First, a bit of history

In 1996, the USB standards organization released the first USB specification, which defined two speeds for USB devices: low speed (1.5 Mbps) and full speed (12 Mbps). At the time, the idea of “hot plugging” a device (plugging in and unplugging without needing to reboot), was revolutionary. USB also supported different ways to transfer data: bulk, for devices like printers that send a lot of data and forget about it; isochronous, for devices like speakers that continuously receive data in a specific order; and interrupt, for devices like keyboards that only send data once in a while.

The 1996 specification also moved the complexity from the USB device into the PC, making devices cheaper and simpler to implement. These features made USB the most attractive external device connector. As a result, device makers adopted USB and joined the standards body to define common interfaces between software and hardware for different classes of devices. These common interfaces allow a single software driver, a class driver, to support an entire type of device. From the beginning, Microsoft embraced the USB technology and the standards organization, contributing to many specifications over the years. We introduced USB 1.1 support in Windows 95 OSR 2.

In 2000, the USB 2.0 specification came to light with a new, high speed (480 Mbps). Unfortunately, the host controller, the hardware used to connect a PC to devices, was not compatible with earlier versions. High speed devices worked with all controllers, but low and full speed devices could not work with USB 2.0 controllers. PCs needed to ship with two different controllers, or embed a USB 2.0 hub, in order to support all types of devices. In Windows XP SP1, we enhanced our existing software driver stack by adding USB 2.0 functionally.

The path to USB 3: start with a solid specification

By actively participating in the USB standards organization, we helped create a specification that was both compelling and interoperable. Like other members of the USB Implementer’s Forum, we wanted to see a faster, more power-efficient version of USB, where, unlike USB 2.0, a single combination of hardware and software could work with all USB devices.

In 2008 the USB Standards organization released the new USB 3.0 specification, which included a new host controller and defined the new “SuperSpeed” USB device (5 Gbps). Together, the controller and device could operate at theoretical speeds of up to 10 times faster than USB 2.0. With this new standard, you’d be able to copy a high definition movie from a USB storage drive in about 80 seconds instead of the 15 minutes it takes with USB 2.0. The specification also introduced a new transfer type —streams — which allows the storage drives to process reads and writes more efficiently.

The new specification provided 80% more power than USB 2.0. This meant faster charging and removed the need for odd “Y” cables used by external DVD drives and other high power devices. But charging isn’t the only power consideration. With mobile computing, people want PCs that conserve battery life. By also introducing new low power states, finishing tasks more quickly, and powering down at every opportunity, USB 3.0 is more power efficient than its predecessors. This translates to longer battery life for notebooks and less power consumption for desktops.

Most importantly, the specification promises to enable a new generation of USB while maintaining compatibility with full, low, and high speed devices. Even the plugs are backwards compatible.

Close partnership with the hardware industry

As the specification began to solidify, we started to design Windows and faced our first difficult decision. Do we update our existing USB software, which we’ve gradually modified since Windows 95 OSR2, or, do we write new software following modern design principles? Countless devices and their drivers rely on the behavior of our existing software, so we couldn’t simply jump into a brand new design. The solution? Don’t jump in. Instead, meticulously design a new USB software stack for the new controller while maintaining existing interfaces and behaviors, ensuring every device and driver will work. For older controllers, we retained our existing software stack.

To create a brand new USB software stack, we had to start work early. If we waited for hardware to be available we would be too late to support the budding USB 3.0 ecosystem. We decided to start before there were any USB 3.0 devices by building “virtual” devices. Virtual devices are software representations of real, physical USB hardware: the ports, the hubs, and other devices.

With virtual device development underway, we started designing and prototyping. USB software is complex because it has to manage hubs and devices while still dealing with any errors. To create something with longevity we needed to visualize and document the flow. We designed three massive flow charts and a code generator to automatically convert a Visio diagram into software. Together with Microsoft Research, we refined a tool called Zing, which could validate every aspect of this software model.

 Figure 3 - Flow chart with its architects, Randy Aull and Vivek Gupta
Flow chart with its architects, Randy Aull and Vivek Gupta

Once we finished some initial development, the first USB host controllers arrived. We recognized that simulation provided a great starting point, but it wasn’t enough. With hardware, we identified incorrect assumptions, timing issues, and other problems unique to real-world scenarios. The path forward also required us to help foster a new ecosystem that would require a strong collaboration with our hardware partners. We needed to work together to prototype, exchange ideas, have deep technical discussions, and report bugs in both directions. We had to build a shared commitment to work together closely so we could identify issues before designs were final.

As USB 3.0 development progressed, so did a sense of community. Software is only as successful as the hardware it enables. Together with our partners in the hardware industry, we were finding issues, developing solutions, and creating the foundation for a new USB ecosystem.

I test, therefore I am

While we were focused on building support for USB 3.0 chips inside the PC, we couldn’t ignore the world of devices. We had to think outside the box – literally. There are over 10 billion USB devices worldwide. Some are in use daily and some are tucked away collecting dust, but all were originally designed to work with Windows PCs. Compatibility is the Windows promise. Our customers have grown  accustomed to expecting new versions of Windows to work with their existing devices and drivers. This commitment to compatibility remains a high priority for Windows 8 across the whole product.

For USB compatibility testing, the “brute force” approach does not work because there are so many devices, with new ones appearing every day, and many old devices that can no longer be purchased. We needed to develop a smart device test strategy.  After analyzing the device statistics, we broke devices into three main categories:

  1. Device popularity
    When looking at the telemetry sources for the most popular devices, we noticed a pattern. Each device class (keyboard, webcam, printers, storage, etc.) had a handful of prevalent manufacturers with just a few main product lines. After projecting these findings, we could represent 70-80% of devices with a few hundred devices. Testers use the mathematic term “equivalence classing” to describe this work.
  2. Chipset
    We still had a significant percentage of devices that would go untested if we just settled for popularity data, so we looked deeper at the actual circuit design. Just like humans, devices that appear very different on the outside are pretty similar on the inside. If we could ensure all USB chipsets worked, then it’s highly likely the devices that contained them would work as well.  A relatively small number of chipset makers are embedded in devices, so we chose to represent their USB IP with development boards.
  3. High-profile and challenging devices
    It’s not often a USB device tops the support call lines. When it does, we want to make sure Windows will work with it going forward.

After 10 years of USB experience, a dozen telemetry sources, and tons of research and brainstorming, we were able to reduce the USB compatibility effort to roughly 1000 unique devices that we regularly test in the Windows labs. We ensure the devices get recognized correctly when connected to PCs, that they sleep and resume appropriately to conserve power, and that they are able to withstand various stress conditions. Our telemetry data indicates that over 90% of devices rely on the 16 class drivers in Windows, but for the more customized devices, we verify that their drivers get seamlessly downloaded from Windows Update whenever possible (the device maker needs to cooperate to support this scenario). With USB 3.0 providing full backwards compatibility, older drivers will still work without any changes.

We also made a heavy investment in building a custom tool – the Microsoft USB Test Tool (MUTT) to simulate a full range of device behaviors that we’d observed over the years. We built the MUTTs from the ground up, in house. Our software test engineers laid out the circuit design with the help of fancy design tools (MS Paint … seriously). They then developed the firmware and generated new test content to run internally. The MUTT was born – think of it as 1,000 devices on a USB thumb drive. Over time, we shared the MUTT with our hardware partners and they’ve used it to find and correct problems in their devices before releasing.

Figure 4 - MUTT Designer David Hargrove, with MUTT device
MUTT Designer, David Hargrove, with MUTT device

Demonstration video

Perhaps the most important aspect of USB 3.0 is the expectation that customers have of USB: it’s just USB3 so it should just work, right? Each and every USB device, low, full, high, and SuperSpeed, has to work in Windows 8. That’s our focus while also delivering the most robust and reliable USB stack.

Let’s take a look at USB 3.0 in action as it takes on some pretty significant copy tasks and races against USB 2.0.

If you don’t see a video here or can’t play it, download it here: High quality MP4 | Low quality MP4


Introducing the team

  • 260

Thanks for the comments and the flood of email we received (and to the number of folks now following us on Twitter, too). It is definitely humbling to see all the enthusiasm and interest. There are clearly already few important threads in the initial comments, some of which are based on the previews of the Windows 8 user experience. We’re definitely gearing up to discuss these issues, the design, and tradeoffs. Windows 8 has new features across the full breadth of the product. It takes quite a team to build Windows 8, and so I thought it would be a good idea to talk about the team structure—sometimes the “how” can help folks to understand the “what” and the “why.”  This will give you an outline of the places we added features to Windows 8.  It will also serve as a bit of a guide as we talk about the product.

It is tempting for some to think of Windows as one entity or group, or for some to think of Windows as just a set of specific people. Sometimes someone speaks at a conference or has a blog, and that comes to represent the product for you. In reality, Windows is always a product of the whole team and much of Microsoft.  Nearly every development group contributes to building Windows 8 in some form or another.  And Windows contributes efforts to most other groups as well.

Windows is a fairly broad project made up of a set of coordinated smaller projects. When we started building Windows 8 we had a clear sense of the direction we were heading and so we built a team structure to support that direction.  Many of the teams work together while at the same time we try to break the work down into fairly independent groups—obviously as a customer you want things to work together, but as an engineer, you also want to be able to work independently. That’s a fine balance we work to maintain.

A lot goes into building a team structure to get all the work of Windows done. The most important first step is deciding “what” we plan to get done, so that we can make sure we have the best teams in place and the best structure to do that work. At the same time we have to make sure all the engineering processes—like daily builds, integration, quality, security, and all the fundamentals—are integral from the start (lots to talk about on these topics!).

We have several engineering roles, or disciplines, that make up our team. The implementation work on Windows happens when developers write code. This code implements features that come from specifications written by program management along with interaction designs from our product designers.  Testers are responsible for making sure the spec is complete and the code does what the spec says it should do. This is a simplified view of the relationship between roles, since we routinely walk a bit in each other’s shoes. There are several other equally important roles on the team, but we tend to think of our engineering effort as development, test, and program management working together in lockstep throughout the entire release—each role has an equal voice in the outcome and choices we make.

We organize the work of Windows into “feature teams,” groups of developers who own a combination of architectural elements and scenarios across Windows.  We have about 35 feature teams in the Windows 8 organization.  Each feature team has anywhere from 25-40 developers, plus test and program management, all working together. Our teams are all focused on building a global product, and so some of our teams are located outside the US and are also delivering globally.

In general a feature team owns and builds what that most folks would identify as an area or component of Windows. “Feature” is always a tricky word—some folks think a feature is a broad architectural component like the “user interface” or networking, and other folks might think a feature is something more specific, like the “start menu” or IPv6.  So the term is a bit overloaded. When we set up different feature teams, we pair the architecture (code, subsystems, components) with the scenarios (user experience) in which users will encounter it, while also working to make sure we keep teams small and manageable.  We long ago stopped trying to count new features because of the difficulty in defining a feature.  We do count work items, which do map to the work and specs that we build (but that is a pretty long list).

When folks do the math and come up with the number of developers on the team, we usually hear one of two reactions: “wow, that is a lot, and there is no way that can work,” or “wow, you build a product for a billion people with a pretty small number folks.” It is to our benefit to have the smallest number of people on the team possible, but it is to your benefit to have the largest number of people adding all the things that folks might want. So, we find a place in the middle. We want the team to be manageable and able to produce high quality, full-featured code.

I mentioned earlier that Windows contributes code to lots of other products and vice versa, so when you look at this list, keep in mind there are features from other groups (for example, our browser language runtime comes from the development tools group) and some of the work here goes into other products, too.  For example, all of our kernel, networking, storage, virtualization, and other fundamental OS work is also part of Windows Server—that’s right, one team delivers the full Windows Client OS and much of the foundation for the Windows Server OS. And some features are built in the core OS but are ultimately only part of the Server product.

Many of the teams listed below describe features or areas that you are familiar with or that you can probably figure out based on the name.  As we post more, team members will identify themselves as part of these teams.  We also have organized these teams in seven larger groups that pull related teams together—fundamentals, devices and networking, core OS, developer experience, user experience, web services, and our engineering system. The Windows Live group (Hotmail, Messenger, Skydrive,  Photos, LiveID, and more) also has a similar structure. Internet Explorer group is also a couple of teams on its own, but obviously contributes across Windows 8.

  • App Compatibility and Device Compatibility
  • App Store
  • Applications and Media Experience
  • App Experience
  • Core Experience Evolved
  • Device Connectivity
  • Devices & Networking Experience
  • Ecosystem Fundamentals
  • Engineer Desktop
  • Engineering System
  • Enterprise Networking
  • Global Experience
  • Graphics Platform
  • Hardware Developer Experience
  • Human Interaction Platform
  • Hyper-V
  • In Control of Your PC
  • Kernel Platform
  • Licensing and Deployment
  • Media Platform
  • Networking Core
  • Performance
  • Presentation and Composition
  • Reliability, Security, and Privacy
  • Runtime Experience
  • Search, View, and Command
  • Security & Identity
  • Storage & Files Systems
  • Sustained Engineering
  • Telemetry
  • User-Centered Experience
  • Windows Online
  • Windows Update
  • Wireless and Networking services
  • XAML

In addition to these teams made up of development, test, and program management, there are many others that are part of the product development team. Our content development team writes and edits our online assistance, website, deployment documents, and SDKs, to name a few things. Product planning leads customer and market research and also pays very close attention to feedback and telemetry around the pre-release software. Product design develops the overall interaction model, graphical language, and design language for Windows 8. Our research and usability team creates field and lab studies that show how existing products and proposed features perform with all types of customers. Localization brings Windows to over 100 languages (and localizes this blog).  Our operations team runs services that are used by hundreds of millions of people and almost a billion PCs.  Just to name a few..

When we started Windows 7 some people told us that the Windows team was too big and had reached a size that caused more engineering problems than it solved. At the same time, you can look at all the comments and see the incredible demand for new features across a very wide range of scenarios.

Folks want new things, and changes to existing things; they want features to be available globally, to be accessible, and to be super high quality; they want things to work on existing hardware, and to take advantage of the latest new hardware. Our job is to get as much done in as short a time as possible, at a very significant scale. That’s all a pretty significant engineering effort.

For folks who are counting my words, I am still under 1,500 words, so I think I will call this an introduction to the team. Keep the comments coming, as they are helping us get ideas for posts and shape the dialog. I hope this post helps to develop some shared context in terms of talking about Windows 8.


About this blog and your comments

  • 71

Thank you very much for the warm reception. It is humbling to see the amount of interest and enthusiasm for the blog and for Windows.  We’ve been digesting all the comments (lots of mail is going around internally about specifics) and I’ve been going through my overflowing inbox (I can’t reply to every message, but I have been replying)!  Thank you.  The most popular question/comment is about “signing up for the beta”.  We will be up front and very visible with any pre-release software programs that you can opt into.  Promise.

As we begin our discussion of building Windows 8 on this blog, two housekeeping topics are worth a post before we start talking about building Windows 8 and the product. We want to be up front about the writing on this blog and provide a view on comments.

This blog is 100% authentic “engineer written” and not a marketing or communications effort. We do not have ghost-writers, editors, or any process that attempts to sanitize the words of folks on the team other than some basic copy editing.

This has the benefit of giving you truly authentic posts that directly reflect the passion of those developing the product. It also means that this blog is not written by professional writers. Some posts will go into a lot of detail. Posts by different writers will all have different “voices.” We ask that folks not be critical of the writing, keeping in mind the direct approach we are taking—I promise you that every writer will take personal comments, well, personally.

We had a long discussion about how to handle comments for Building Windows 8 (“B8”). Our experience with the Engineering Windows 7 blog (“E7”) comments was mostly positive, but a non-zero number of folks abused their direct access to both email and comments. Let’s keep the comments in the spirit of the community and avoid using comments for unrelated topics.

Of course, the primary goal of this blog is to have a two-way dialog, so comments are an important part of what we’re looking for with our blogging efforts. So we opted for the commenting mechanism already used by thousands of MSDN blogs—anonymous comments are permitted, and they appear without moderation. This blog platform employs some minor security measures and a spam filter that we do not control.

That means we are seeking out comments. Everyone on the Windows team will be watching for comments and is looking forward to the dialog. When participating, we will work to make sure Microsoft employees represent themselves as such, especially indicating if they work on the area Windows being discussed. We ask that press (those that write, blog, tweet professionally) identify themselves accordingly as well.

Things we hope to see in comments:

  • Lots of on-topic, good, interesting thoughts on Windows and the posts on B8
  • Focus on the content of the post and not just the topic in general—seek out the details
  • Dialog that is respectful and fun

We reserve the right to delete comments or otherwise edit what has been said. Things that will get comments edited or deleted:

  • Offensive or abusive language or behavior as determined by a community standard
  • Misrepresentation (i.e., claiming to be somebody you’re not) — if you don’t want to use your real name, that’s fine, as long as your profile name isn’t offensive, abusive, or misrepresentative
  • Repeatedly posting the same comments or agenda, or attempting to fit a specific topic into every post, no matter what we blog about
  • Blog-spam or link-abuse of any kind

We hope these rules will keep the discussion lively and on-topic.


No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: