Engineering Windows 7

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

October, 2008

  • Engineering Windows 7

    User Account Control

    • 188 Comments

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

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

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

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

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

    The Why of UAC

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

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

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

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

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

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

    What we have learned so far

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

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

    Impact on the software ecosystem

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

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

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

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

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

    Percentage of sessions with prompts over time. 

    Figure 3. Percentage of sessions with prompts over time.

    Impact on Windows

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

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

    Number of Microsoft prompters in the top 50 over time.

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

    Impact on Customers

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

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

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

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

    Percentage of prompts over time per prompt type.

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

    Percentage of UAC prompts allowed over time.

    Figure 6. Percentage of UAC prompts allowed over time.

    Looking ahead…

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

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

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

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

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

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

    Ben Fathi

  • Engineering Windows 7

    Windows Desktop Search

    • 139 Comments

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

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

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

    Why Index?

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

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

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

    Trade-Offs

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

    A Model Citizen

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

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

    Constantly Improving

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

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

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

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

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

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

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

    Chris McConnell

    Find and Organize

  • Engineering Windows 7

    User Interface: Managing Windows windows

    • 135 Comments

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

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

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

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

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

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

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

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

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

    Data on Real-World Usage 

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

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

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

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

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

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

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

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

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

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

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

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

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

    Evolving the design

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

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

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

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

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

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

    - Dave

  • Engineering Windows 7

    Follow-up: Managing Windows windows

    • 121 Comments

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

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

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

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

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

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

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

    Put the windows where I want them

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

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

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

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

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

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

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

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

    Open at the right size

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

    @magicalclick suggested a solution:

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

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

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

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

    –steven

    Finding the right window

    The word being used is “Expose”:

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

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

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

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

    Dragging files

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

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

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

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

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

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

    - Dave

  • Engineering Windows 7

    Follow-up: Windows Desktop Search

    • 77 Comments

    The discussion and email about desktop search offered an opportunity for us to have a deeper architectural discussion about engineering Windows 7.  There were a number of comments suggesting alternate implementation methods so we thought we’d discuss another approach and the various pros and cons associated with it.  It offers a good example of the engineering balance we are striving for with Windows 7.  Chris McConnell wrote this follow-up.  --Steven (See you at the PDC in a week!)

    Thanks for all the great feedback on our first blog post on Windows Desktop Search.  I’ve summarized a number of points that have been made and added some comments about the architectural choices we have made and why.

    Integration with the File System

    As some posters have pointed out, one possible implementation is to integrate indexing with the file system so that updating a file immediately updates the indices.  Windows Desktop Search takes a different approach.   There are two aspects of file system integration: knowing when a file changes and actually updating the indices before a file is considered “closed” and available.   On an NTFS file system, the indexer is notified whenever a file changes.   The indexer never scans the NTFS file system except during the initial index.  It is on the second point—updating the indices immediately when a file is closed that we made a different choice.  Updating immediately has the benefit that a file is not available until it is indexed, but it also comes with a number of potential disadvantages.  We chose to decouple indexing from file system operations because it allows for more flexibility while still being almost real-time.   Here are some of the benefits we see in the approach we took:

    1. Fewer resources are used.  Inverted indices are global.  An inverted index maps from a word found in a property to a list of every document that contains that word.  Indexing a single file requires updating an index for every single unique word found in the file.   A single document might then update a very large number of individual indices.  Making these changes and committing them with the same robustness found on individual files would be very expensive.  The design of the indexer allows scheduling and aggregating these changes so that much less work is done overall—that means less CPU and less disk I/O.  The system can be more robust because indexing doesn’t only happen when a file is closed—and it can even be retried if necessary.
    2. File system operations are prioritized over indexing.  Getting files robustly updated and available is necessary for applications to use them.  We don’t want to delay that availability by forcing the cost of indexing into file close operations.   Searching over files is important, but is less important than actually working with files.  We wouldn’t want applications to decide individually if the indexer should be turned on or off just because they were seeking the best performance with respect to the file system.
    3. There are lots of file types.  Microsoft supplies extractors (IFilter/IPropertyHandler) for many common file types as part of Windows.  There are many other file types as well so it is important to allow non-Microsoft developers to write their own extractors.  In Vista (and Windows 7), these extractors run in a locked down process that ensures that they are secure and do not affect the performance of the whole system.  If indexing had to happen before a file was available, then an extractor could impact (intentionally or not) all file system operations.  
    4. Some files are more valuable to index then others.  If indexing happened when a file is closed, then there is no control over the order files are indexed.  Decoupling allows prioritizing indexing some files over others.  For example, searching for music is much more likely than searching for binary files.  If both music files and binary files have changed, then the indexer ensures it indexes the music files first.  Some files are not worth indexing at all for most people.  Several comments suggested that we should index the whole drive.  We can do that—and for those who would find it valuable it easy to add folders to be indexed.  (You can also remove them, but that is much less common so that is controlled through the control panel “Indexing Options.”)  For most people indexing system files is just a cost—they would never search for them and would be confused if they showed up as the result of a search. 
    5. Not everything is a file in single file system.  Windows is all about supporting diversity.  There are many different file systems like FAT32 and CDFS and we would like to be able to search over those as well.   If we integrated with only NTFS, then we would have to still have a loosely coupled system for other file systems.  Many applications also have databases optimized for their own needs.  For example, Outlook has a database of email.  If only files were indexed, then the email in the database could not be indexed unless Outlook either compromised their experience by using files only, or complicated their implementation by duplicating everything in both the file system and the database.

    Advanced Queries

    A number of people expressed frustration with the lack of an advanced query UI.  Microsoft has many advanced query user-interfaces in many products, but these are generally focused on well-defined query languages (SQL) or on specific domains (like the Advanced Find in Outlook).  With Vista we wanted to address the query problem in a manner more familiar to people today—a single edit control.  Our implementation supports a rich query language within that edit control.  This is the same approach people are familiar with for web searching for both standard and advanced queries.

    We had two observations that led to this approach:

    1. The most important part of a search are the search terms.  Usually a single term is enough (and as we know from web searching, the majority of searches are one or two words).   And for refinement the file system tools of thumbnails, sorting, and/or type ahead can be used to narrow the search.  
    2. It is reasonable to consider a design for an advanced query UI covering property based search, but it will generally be unwieldy for all but the bravest people.  As we mentioned, Windows Search covers over 300 properties by default so if you show every property then the UI is unusable.  If we only show the most commonly used properties then how do you handle all of the other properties?  Would properties be grouped by the common application or by attributes such as times, names, file attributes, etc.?  Some of you might value the Outlook Advanced Find… interface, but there you see some of the challenges and that is within a specific domain where the grouping or related properties probably can be understood. 

    In designing Vista we incorporated the feedback that it is desirable to do precise queries.  The approach taken in Vista was to support a rich query language which allows all properties and a fairly natural syntax.  For example typing “from:gerald sent:today” will find all email from “Gerald”  sent today!   The big issue is that people do not know or the query language.  In Windows 7, we have focused on helping people see how to use the query language in context. For now, you can see the following for some information on Vista’s query syntax.  Much of this syntax and experience is similar to web search that we all use today.

    A number comments were about substring matches in filenames, which we do not currently support.  This is part of the overall discussion about advanced queries.  In order to efficiently execute queries, the indexer builds indices that are based on individual words.  In Vista we introduced “searching as you type” to our search UI.  Under the hood this is implemented as prefix matches on the indexed words.  So when you type, ‘foo’, we look for all terms that start with those letters including ‘food’ and ‘football’.    Even more interesting if you type ‘foo net’ we will match on items that have the words ‘food’ and ‘network’ in them.   (If what you really want is to match the phrase “foo net” then typing those words inside quotes will do that—another example of advanced query syntax)   We have focused primarily on searching for terms found in any property, but there is no question that filenames are special.  In recognition of that we support suffix queries on filenames.  If you type ‘*food’ then we will return files that end in ‘food’ like “GoodFood”.  We do this by reversing the filename and then indexing it as a word.  For example, the reverse filename of “GoodFood” would be “DooFdooG” which we index as a word.  The suffix query ‘*food” is transformed into a prefix query “doof*” over the reverse filename index—clever, no?   So we support prefix matches for all properties and suffix matches for filenames, but we do not support substring matches. 

    Performance and Citizenship

    A number of comments focused on improving performance and citizenship—and we definitely agree on this input.   We are always striving to make Windows do more with fewer resources.  For those who have turned off indexing all together we hope that our continued improvements will make you reconsider.  Even if you organize all of your files and don’t find search useful for files, perhaps you will find start menu search, email search or Internet Explorer 8 address bar search useful.  We have worked hard at improving performance and citizenship across Windows.  Some of this progress is visible in WS4 and soon in Windows 7.  We have improved along all of our dimensions including indexing cost, battery life, citizenship, query speed and scrolling speed.  We have some tremendous tools that help us track down performance problems.  If you want to help, please contact idx-help@microsoft.com and we will tell you how to collect performance traces we can analyze so that we can continue to make improvements.

    Chris McConnell

    Find and Organize

  • Engineering Windows 7

    From Idea to Feature: A view from Design

    • 67 Comments

    Larry is very appreciative of the reception and comments his post received. Thank you!  It is worth noting that we’ve surpassed over 2000 comments and I’ve received and equal amount of email. I am trying to reply as often as I can! 

    We’re 10 days from the PDC and so we might take a short break from the blog while we practice our demos of Windows 7…we’ll keep an eye on comments for sure and maybe a post or two on the way.  :-)

    Let's move "up" in the dev process and look at how we come up with what is in a release and how we think about taking a feature from an idea to feature. 

    As we’ve posted on various engineering challenges we’ve often distilled the discussion down to a few decisions, often between two options (make a feature optional or not, add a window management feature one of two ways, etc.) Yet this doesn’t quite get to the challenge of where does the product definition begin and how do we take an idea and turn it into a feature. Most choices in engineering Windows are not between two choices, but the myriad of considerations, variables, and possibilities we have before we even get to just a couple of options. This post looks a bit at the path from an idea to a feature.

    A common thread we’ve seen in the feedback is to make “everything customizable and everything optional” (not a direct quote of course). Of course, by virtue of providing a platform we aim to offer the utmost in extensibility and customization by writing to the APIs we provide. There is an engineering reality that customization and extensibility have their cost—performance, complexity, and forward compatibility come to mind. One way to consider this is that if a feature has two “modes” (often enable the new feature or enable the old feature) in one release, then in a follow-up release if the feature is changed it potentially has four modes (old+old, old+new, new+old, new+new), and then down the road 8 modes, and so on. The complexity of providing a stable and consistent platform comes with the cost that we aren’t always able to “hook” everything and do have to make practical choices about how a feature should work, in an effort to plan for the future. Designing a feature is also about making choices, tough choices. At the same time we also want to provide a great experience at the core operating system functions of launching programs, managing windows, working with files, and using a variety of peripherals--to name just a few things Windows does. This experience should be one that meets the needs of the broadest set of people across different skill levels and different uses of PCs, and also providing mechanisms to personalize with user interface and to customize with code. Every release we plan is a blending of fixing things that just don’t work like we all had hoped and developing new solutions to both old and new problems, a blending of features and extensibility, and a blending of better support for existing hardware and support for new hardware.

    This post is jointly written by Samuel Moreau the manager of the user experience design team for the Windows Experience, Brad Weed, Director of User Experience Design and Research for Windows and Windows Live, and Julie Larson-Green, the VP of Program Management for the Windows Experience. With the number of comments that describe a specific feature idea, we thought it would be good to give you an overview of how we approach the overall design process and how ideas such as the ones you mention flow into our process. Also for those of you attending the PDC, Sam will be leading a session on the design principles of Windows 7. –Steven

    Designing Windows – from idea to feature

    In general, we follow a reasonably well-understood approach to product design, but that doesn’t make it easy or “automatic”. Often this is referred to as a "design funnel" where ideas go from concept to prototype to implementation and then refinement.  By reading the various design ideas in the comments of Chaitanya’s post on “Starting, Launching and Switching”, you can see how difficult it can be to arrive at a refined feature design. In those comments you can find equally valid, yet somewhat opposite points of view. Additionally, you can also find comments that I would paraphrase as saying “do it all”. It is the design process that allows us to work through the problem to get from idea to feature in the context of an overall product that is Windows.

    From a product design perspective, the challenge of building Windows is the breadth of unique usage of just a single product. In a sense, one of the magic elements of software is that it is “soft” and so you can provide all the functionality to all customers with little incremental cost and little difference in “raw materials” (many comments have consistently suggested we have everything available along with options to choose components in use and we have talked about minimizing the cost when components and features are not used even if they are available). And at the same time, there is a broad benefit to developers when they can know a priori that a given PC has a common set of functions and can take advantage of specific APIs that are known to be there and known to behave a specific way--the platform. This benefit of course accrues to individuals too as you can walk up to any PC and not only have a familiar user experience, but if you want to do your own work, use a specific device, or run a certain program on the PC you can also do that. This breadth of functionality is a key part of the value of a Windows PC. Yet it also poses a pretty good design challenge. Learning, understanding, and acting on the broad set of inputs into designing Windows is an incredibly fun and challenging part of building Windows.

    As Larry pointed out the design and feature selection happens takes place in his part of the organization (not way up here!). There’s another discussion we will have in a future post about arriving at the themes of the overall release and how we develop the overall approach to a release so that the features fit together and form a coherent whole and we address customer needs in an end-to-end fashion.

    We have a group of product designers that are responsible for the overall interaction design of Windows, the sequence and visualization of Windows. Program Managers across the team work with product designers as they write the specifications. Along with designers we have UX Researchers who own the testing and validation of the designs as we’ve talked about before. The key thing is that we apply a full range of skills to develop a feature while making sure that ownership is clear and end-to-end design is clear. The one thing we are not is a product where there is “one person” in charge of everything. Some might find that to be a source of potential problems and others might say that a product that serves so many people with such a breadth of features could not be represented by a single point of view (whether that is development, testing, design, marketing, etc.). We work to make sure engineers are in charge of engineering, that the product has a clear definition that we are all working towards implementing and that product definition represents the goals across all the disciplines it takes to deliver Windows to customers around the world.  And most importantly, with Windows 7 we are making renewed effort at "end to end" design.

    Let’s look at the major phases of product design in Engineering Windows. What we’ll talk about is of course generalized and doesn’t apply to each specific incident. One thing we always say internally is that we’re a learning organization—so no process is perfect or done and we are always looking to make it better as we move through each and every iteration of building Windows.

    Throughout this post when we say “we” what this really means is the individuals of each discipline (dev, test, pm, design) working together—there’s no big feature or design committee.

    Pick the question or get an idea

    We get an idea from somewhere of something to do—it could be big (build UX to support a new input method such as touch), wild (change the entire UI paradigm to use 3D), or an improvement / refinement of an existing feature (multi-monitor support), as some examples. There is no shortage of creative ideas, because frankly, that is the easy part. Ideas flow in from all corners of the ecosystem, ourselves included. We’ve talked a lot about comments and feedback from this blog and that is certainly one form of input. Product reviews, enterprise customers, customer support lines, PC makers, hardware and software developers, blogs, newsgroups, MVPs, and many others have similar input streams into the team.

    The key is that working on Windows is really a constant stream of inputs. We start with a framework for the release that says what goals and scenarios we wish to make easier, better, faster. And with that program management builds up candidate ideas—that is ideas that will make their way through features. The job of getting a feature “baked” enough falls to program management and they do this work by working across the product and working with design, development, and testing (as Larry described).

    With regard to where ideas come from, what we like to say is that the job of program management is not to have all the great ideas but to make sure all the great ideas are ultimately picked. The best program managers make sure the best ideas get done, no matter where they come from.

    Gather information and data

    Given any idea, the first step is to understand what data we have “surrounding” the idea. Sometimes the idea itself comes to us in a data-centric manner (customer support incidents) or other times it is anecdotal (a blog).

    The first place we look is to see what data do we have based on real world usage that would support the development of a hypothesis, refute or support the conventional wisdom, or just shed some light on the problem.  The point is that the feature starts its journey by adding more perspectives to the input.

    Essentially, we need an objective view that illuminates the hypothesis. We gather this data from multiple sources including end users, customers, partners, and in various forms such as instrumentation, research, usability studies, competitive products, direct customer feedback, and product support.

    As many (including us) have pointed out, telemetry data has limitations. First, it can never tell you what a person might have been trying to do—it only tells you what they did. Through usability, research, and observation, we are able to get more at the intent.  For example, the way we talked about high dpi and how the telemetry showed one thing but the intent was different (and the impact of those choices was unintended). The best way to see this is to remember that a person using a PC is not interesting in “learning to use a PC” but is trying to get their own work done (or their own playtime). And when faced with a “problem” the only solutions available are the buttons and menu commands right there—the full solution set is the existing software. Our job is to get to the root of the problem and then either expand the solution set or just make the problem go away altogether.

    What about unarticulated needs?  The data plus intent shows the “known world” and “known solution space”, but one role we have is to be forward thinking and consider needs or desires that are not clearly articulated by those who do not have the full time job to consider all the potential solution spaces. The solution space could potentially be much broader than readily apparent from the existing and running product—it might involve a rearchitecture, new hardware, or an invention of a new user interface.

    A great example of this was mentioned in one of the comments on the taskbar post. The comment (paraphrasing) indicated that the order of icons on the taskbar matters so sometimes he/she would simply close all the open programs and then restart them just so the programs were in the preferred order on the taskbar. Here the data would look like an odd sequence of launch/exit/launch/exit/launch/lauch. And only through other means would we learn why someone would be doing that, and for the most part if you just walked up without any context and said “how can we make Windows easier” it isn’t likely this would bubble up to the top of the list of “requests”. Thus we see a number of neat things in this one example—we see how the data would not show the intent, the “request” would not be at the top of any list, and the solution might take any number of forms, and yet if solved correctly could be a pretty useful feature. Above all, in hindsight this is one of those “problems” that seems extraordinarily obvious to solve (and I am sure many of you are saying—“you should have just asked me!”) So we also learn the lesson that no matter what data and information we gather or what design we’re talking about, someone always noticed or suggested it :-).

    Hypothesize

    The next step is where we propose a clear hypothesis – “people would benefit from rearranging icons on the taskbar because positional memory across different sessions will reduce the time to switch applications and provide a stronger sense of control and mastery of Windows”.

    What is our hypothesis (in a scientific sort of way) as to what opportunity exists or what problem we would solve, and what the solution would look like, or why does the problem exist?  Part of designing the feature is to think through the problem—why does it exist—and then propose the benefit that would come from solving the problem. It is important that we have a view of the benefit in the context of the proposed solution. It is always easy to motivate a change because it feels better or because something is broken so a new thing has to be better, but it is very important that we have a strong motivation for why something will benefit customers.

    Another key part about the hypothesis is to understand the conventional wisdom around this area, especially as it relates to the target customer segment (end-user, enthusiast, PC maker, etc.) The conventional wisdom covers both the understanding of how/why a feature is a specific way today and also if there is a community view of how something should be solved. There are many historic examples where the conventional wisdom was very strong and that was something that had to be considered in the design or something that had to be considered knowing the design was not going to take this into account—a famous example is the role of keyboard shortcuts in menus that the “DOS” world felt would be required (because not every PC had a mouse) but on the Mac were “unnecessary” because there was always a mouse. Conventional wisdom in the DOS world was that a mouse was optional.

    Experiment

    For any hypothesis, there are numerous design alternatives. It is at this stage where we cast a broad net to explore various options. We sketch, write scenarios, story board, do wireframes and generate prototypes in varying fidelity. Along the way we are working to identify not just the “best answer” but to tease out the heart and soul of the problem and use the divergent perspectives to feed into the next step of validation.

    This is a really fun part of the design process. If you walk our hallways you might see all sorts of alternatives in posters on the walls, or you might catch a program manager or designer with a variety of functional prototypes (PowerPoint is a great UI design tool for scenarios and click-thrus that balance time to create with fidelity, and Visio is pretty cool for this as well) or our designers often mock up very realistic prototypes we can thoroughly test in the lab.

    Interpret and Validate

    With a pile of options in front of us we then take the next step of interpreting our own opinions, usability test data and external (to the team) feedback. This is the area where we end up in conversations that, as an example, could go something like this… “Option ‘A’ is better at elevating the discovery of a new feature, but option ‘B’ has a stronger sense of integration into the overall user experience”.

    As we all know, at the micro level you can often find a perfect solution to a specific problem. But when you consider the macro level you start to see the pros and cons of any given solution. It is why we have to be very careful not to fall into the trap of a “tests”. The trap here is that it is not often possible to test a feature within the full context of usage, but only within the context of a specific set of scenarios. You can’t test how a feature relates to all potential scenarios or usages while also getting rich feedback on intent. This is why designing tests and interpreting the results is such a key part of the overall UX effort led by our researchers.

    A mathematic way of looking at this is the “local min” versus a “global min”. A local min is one you find if you happen to start optimizing at the wrong spot on the curve. A good example of this in software is when faced with a usability challenge you develop a new control or new UI widget. It seems perfectly rational and often will test very well, especially if the task asked of the subject is to wiggle the widget appropriately. However, what we’re after is a global optimization where one can see that the potential costs (in code, quality, and usability) of another widget by erase any potential benefits gained by introducing a new widget. Much has been written about the role of decision theory as it relates to choosing between options, but our challenge with design is the preponderance of qualitative elements.

    Choosing

    Ultimately we must pick a design and that choice is informed by the full spectrum of data, qualitative and quantitative.

    Given a choice for a design and an understanding of how to implement it and the cost, there is still one more choice—should we do the feature at all. It sounds strange that we would go through all this work and then still maybe not build a specific feature. But like a movie director that shoots a scene that ends up on the cutting room floor, sometimes the design didn’t pan out as we had hoped, sometimes we were not able to develop an implementation plan within reason, or sometimes there were other ideas that just seemed better. And this is all before we get to the implementation, which as Larry pointed out has challenges as well.

    We have two tools we use to assist us in prioritizing features and designs. First is the product plan—the plan says at a high level what we “require” the product to achieve in terms of scenarios, business goals, schedule, and so on. Most of the time features don’t make it all the way through prototyping and testing because they just aren’t going to be consistent with the overall goals of the release. These goals are important otherwise a product doesn’t “hang together” and runs the risk of feeling like a “bunch of features”. These high level goals inform us quite a bit in terms of what code we touch and what scenarios we consider for a release.

    And second we have the “principles of design” for the release. These principles represent the language or vocabulary we use. These represent the core values—we often think of the design principles as anthropomorphizing the product—“if Windows were a person then it would be…”. This is the topic of Sam’s talk at the PDC.

    As mentioned in the introduction, it isn’t possible to do everything twice. We do have to decide. This could be a whole series of posts—customization, compatibility modes, and so on. We definitely hear folks on these topics and always do tons of work to enable both “tweaking” and “staying put” and at the same time we need to balance these goals with the goals of providing a robust and performant platform and also moving the OS forward. Some of us were involved in Office 2007 and there is a fun case study done by Harvard Business School [note fee associated with retrieving the full text] about the decision to (or not to) provide a “compatibility mode” for Office 2007. This was a choice that was difficult at the time and a few folks have even mentioned it in some comments.

    Implement and Integrate

    Finally, we build and iterate to refine the chosen solution. Inevitably there are new discoveries in the implementation phase and we adjust accordingly. As we integrate the solution into its place in Windows, that discovery continues. The beta period is a good example of how we continue to expand and learn from usage and feedback. In a Windows beta we are particularly interested in compatibility and real-world performance as those are two aspects of the design that are difficult to validate without the breadth of usage we can get if we do a great beta.

    It is important to keep in mind that we follow intensely all the feedback we receive from all forms—reviews, blogs, and of course all the telemetry about how the product is used (realizing that the beta is a select group of people).

    One of the things we hope to do with the blog, as you might have seen on the IE 8 Blog, is to discuss the evolution of the product in real-time. We’re getting close to this transition and are looking forward to talking more about the design choices we made!

    -- Sam, Brad, and Julie

  • Engineering Windows 7

    Engineering 7: A view from the bottom

    • 63 Comments

    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.

    --Larry Osterman

Page 1 of 1 (7 items)