Engineering Windows 7

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

  • Engineering Windows 7

    Windows 7 Battery Notification Messages

    • 303 Comments

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

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

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

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

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

    Consider replacing your battery - Windows 7 notification

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

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

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

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

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

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

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

    Thanks,

    Steven

  • Engineering Windows 7

    What we do with a bug report?

    • 69 Comments

    This has been a busy couple of days for a few of us on the team as we had a report of a bug in Windows 7. The specifics of the issue are probably not as important as a discussion over how we will manage these types of situations down the road and so it seems like a good time to provide some context and illustrate our process, using this recent example.

    This week a report on a blog described a crashing issue in Windows 7. The steps to reproduce the crash were pretty easy (1) run chkdsk /r on a non-system drive then crash after consuming system memory. Because it was easy to “reproduce”, the reports of this issue spread quickly. Subsequent posts and the comments across the posts indicated that the issue seemed to have been reproduced by others—that is the two characteristics of the report were seen (a) consumption of lots of memory and (b) crashing.

    Pretty quickly, I started getting a lot of mail personally on the report. Like many of you, the first thing I did was try it out. And as you might imagine I did not reproduce both issues, though I did see the memory usage. I tried it on another machine and saw the same behavior. In both cases the machine functioned normally during and after the chkdsk. As I frequently do, I answered most of the mail I receive and started asking people for steps to reproduce the crash and to share system dump files. The memory usage did not worry me quite as much as the crash. I began having a number of interesting mail threads, but we didn’t have any leads on a repro case nor did we have a crash dump to work with.

    Of course I was not the first Microsoft person to see this. The file system team immediately began to look into the issue. They too were unable to reproduce the crash and from their perspective the memory usage was by design and was a specific Windows 7 change for this scenario (the /r flag grabs an exclusive lock and repairs a disk and so our assumption is you’d really like the disk to be fixed before you do more stuff on the machine, an assumption validated by several subsequent third party blog posts on this topic). We cast the net further and continued looking for crash dumps and reports. As described below we have quite a few tools at our disposal.

    While we continued to investigate, the mail I was getting was escalating in tone and more importantly one of the people I responded to mentioned our email exchange in a blog post. So in my effort to have a normal email dialog I ended up in the thick of the discussion. As I have done quite routinely during the development of Windows 7, I added a comment on the original blog (and the blog where this particular email friend was commenting) outlining the steps we are taking and the information we knew to date. Interestingly (though not unfortunately) just posting the comment drew even more attention to the issue being raised. I personally love being a member of the broader community and enjoy being a casual contributor even when it seems to cause a bit of a stir.

    It is worth just describing the internal process that goes on when we receive a report of a crashing issue. Years ago we had one of two reactions. Either we would just throw up our arms and surrender as we had no hope of finding the bug, or we would drop everything and start putting people on airplanes with terminal debuggers in the hopes of finding a reproducible case. Neither of these is particularly effective and the latter, while very heroic sounding, does not yield results commensurate with effort. Most importantly while there might be a crash, we had no idea if that was the only instance or if lots more people were seeing or would see the crash. We were working without any data to inform our decisions.

    With the internet and telemetry built into our products (not just Windows 7) we now have a much clearer view of the overall health of the software. So when we first hear a report of a crash we check to see if we’re seeing the crash happen on the millions of machines that are out there. This helps us in aggregate, but of course does not help us if a crash is one specific configuration. However, a crash that is one specific configuration will still show up if there is any statistically relevant sampling of machines and given the size of the user base this is almost certain to be the case. We’re able to, for example, query the call stacks of all crashes reported to see if a particular program is on the stack.

    We have a number of tools at our disposal if we are seeing a crash in telemetry. You might have even seen these at work if you crash. We can increase (with consent) the amount of data asked for. We can put up a knowledge base article as a response to a crash (and you are notified in the Windows 7 Action Center). We can even say “hey call us”. As crazy as that one might sound, sometimes that is what can help. If a crashing issue in an already shipping product suddenly appears then something changed—a new hardware device, new device driver, or other software likely caused the crash to appear far more frequently. Often a simple confirmation of what changed helps us to diagnose the issue. I remember one of the first times we saw this was when one day unexpectedly Word started crashing for people. We hadn’t changed anything. It turned out a new version of a popular add-in released and the crash was happening in the add-in, but of course end-users only saw Word crashing. We quickly put up instructions to remove the add-in while in parallel working with the ISV to push out a fix. This ability to see the changing landscape, diagnose, and respond to a problem has radically changed how we think of issues in the product.

    We are constantly investigating both new and frequently occurring issues (including crashes, hangs, device not found, setup failures, potential security issues, and so on). In fact we probably look into on the order of hundreds of issues in any given month as we work with our enterprise and OEM customers (and therefore hardware partners, ISVs, etc.). Often we find that issues are resolved by code changes outside core Windows code (such as with drivers, firmware, or ISV code). This isn’t about dodging responsibility but helping to fix things at the root cause. And we also make many code changes in Windows, which are seen as monthly updates, hotfixes, and then service pack rollups. The vast majority of things we fix are not applicable broadly and hence not released with immediate urgency—if something is ever broadly applicable we will make the call to release it broadly. It is very important for everyone to understand how seriously we take the responsibility of making sure there are no critical issues impacting a broad set of customers, while also balancing the volume of changes we push out broadly.

    To be specific about the investigation around the chkdsk utility, let’s look at how we dove into this over the past couple of days. We first looked through our crash telemetry (both at the user level and “blue screen” level) and found no reported crashes of chkdsk. We of course look through our existing reports of issues that came up during the development of Windows 7, but we didn’t see anything at all there. We queried the call stacks of existing reported crashes (of all kinds, since this was reported) and we did not find any crashes with chkdsk.exe running while crashing. We then began automated test runs on a broad set of machines—these ran overnight and continued for 2 days. We also saw reports related to a specific hardware configuration, so we set up over 40 machines based on variants of that chipset, driver, and firmware and ran those tests. We were not hitting any crashes (as mentioned, the memory usage was already understood). Because some were saying the machines were non-responsive we also looked for that in manual tests and didn’t see anything. We also broadened this to request globally to Microsoft folks to try things out (we have quite a few unique configs when you think of all of our offices around the world) and so we had several hundred more test runs going. We also had reports of the crash happening when running without a pagefile—that could be the case, but that would not be an issue with this utility as any program that requests more memory than physically available would cause things to tip over and this configuration is not recommended for general purpose use (and this appears to be the common thread on the small number of non-reproducible crashes). Folks interested might read Mark’s blog on the topic of pagefiles in general. While we did not identify anything of note, that does not rule out the possibility of a problem but at this point the chances of any broad issue are extremely small. 

    In the meantime, we continue to look through external blogs, forums and other reports of crashes to see if we can identify any reproducible cases of this. While we don’t contact everyone, we do contact people if the forum and report indicate this has a good chance of yield. In all fairness, it probably doesn’t help us when there’s a lot of “smoke” while we’re trying to find the fire. We had a lot of “showstopper” comments piling on but not a lot of additional data including a lack of a reproducible case or a crash dump.

    This type of work will continue until we have satisfied ourselves that we have systematically ruled out a crash or defined the circumstances where a crash can happen. Because this is a hardware/software related issue we will also invite input from various IHVs on the topic. In this case, because it is disk related we can’t rule out the possibility that in fact the disk was either failing or about to fail and the excessive use of the disk during a /r repair would in fact generate a failure. And while the code is designed to handle these failures (as you can imagine) there is the possibility that the specific failure is itself not handled well. In fact, in our lab (running tests continuously for a few days) we had one failure in this regard and the crash was in the firmware of the controller for the disk. Obviously we’ll continue to investigate this particular issue.

    I did want folks to know just how seriously we take these issues. Sometimes blogs and comments get very excited. When I see something like “showstopper” it gets my attention, but it also doesn’t help us to have a constructive and rational investigation. Large software projects are by nature extremely complex. They often have issues that are dependent on the environment and configuration. And as we know, often as deterministic as software is supposed to be sometimes issues don’t reproduce. We have a pretty clear process on how we investigate reports and we focus on making sure Windows remains healthy even in the face of a changing landscape. With this post, I wanted to offer a view into some specifics but also into the general issue of sounding alarms.

    It is always cool to find a bug in software. Whether it is an ATM, movie ticket machine, or Windows we all feel a certain sense of pride in identifying something that doesn’t work like we think it should. Windows is a product of a lot of people, not just those of us at Microsoft. When something isn’t as it should be we work with a broad set of partners to make sure we can effectively work through the issue. I hope folks recognize how serious we take this responsibility as we all know we’re going to keep looking at issues and we will have issues in the future that will require us to change the code to maintain the level of quality we know everyone expects of Windows.

    --Steven

  • Engineering Windows 7

    Our Next Engineering Milestone: RTM

    • 64 Comments

    Today marks an important milestone in the Windows 7 project. The Windows 7 team is proud to share with you that a short while ago we have started to release Windows 7 to PC OEM and manufacturing partners. This means our next major milestone will be the availability of PCs loaded with Windows 7 and store shelves stocked with Windows 7 on October 22, 2009.

    This is a milestone we could not have achieved without the broad participation across the PC Ecosystem we have talked so much about on this blog. Windows 7 is a product not just of Microsoft, but of a whole industry of partners of all kinds. Throughout the development of Windows 7 we’ve seen an incredible engagement from so many people that have contributed to making the Windows 7 engineering project one we, collectively, feel good about. The feedback and collaboration throughout the development of Windows 7 has been outstanding and valuable beyond measure. This work has created the kind of experience so many of you have talked about in this blog—the ability to use a broad range of PC hardware and peripherals with a great setup and out of box experience. On behalf of the Windows team and all of the successful installations and device connections, please let me extend an incredible “thank you” to all of our hardware partners who have done such excellent work.

    Windows 7 has also been one of the most broadly and deeply tested releases of software we have ever had. Starting with a pre-beta in October of 2008 with a few thousand developers using Windows 7 at the earliest stages, through the Beta, and then the Release Candidate in May when we have had millions of people successfully running the product (and many on multiple PCs). As we have discussed in this forum, the ongoing depth usage of Windows 7 along with the breadth and variety of hardware and software configurations has provided (and will continue to provide) the key tools to make sure we continue to deliver ever-improving Operating System quality.

    In developing Windows 7 we also set out to have a great dialog with you, perhaps our strongest critics and our biggest supporters. We know you expect a lot from Windows 7 and you demand a lot from the team that builds your OS. This blog has helped to bring significant issues and important decisions to light and we have debated them—here and elsewhere. Along the way we have definitely learned a lot about working together and also about many specific issues that are important to you. We have worked hard to find the right balance across many diverse points of view and we hope you share our feeling that we’ve done a good job at being open, honest, and transparent in how we have approached engineering Windows 7. The conversations we had on this blog have been a memorable part of developing Windows 7 and in our hallways, in Redmond and around the world, we’ve spent collectively thousands of hours discussing and acting on the feedback you have provided here.

    While we have reached our RTM Milestone, no software project is ever really “done”. We will continue to monitor and act on the real world experience with Windows 7—we’ve used the Beta and RC process to test out our servicing and we have every intent of doing a great job on this important aspect of the product. Hardware partners will continue to provide new devices and improve support for existing devices. PC makers no doubt have quite a bit in store for all of us as they begin to show off PCs specifically designed for Windows 7’s new APIs and features. Software developers will have lots of new software to show off as well. All of this is yet to come and is very exciting.

    Software projects on the scale of Windows are pretty rare and our team has a lot of pride, and as we have said so many times, is humbled by the responsibility. We are going to continue to learn and continue to improve how we engineer our products, with the aim of being the very best engineers we can be and delivering the very best OS for the world’s varied customers. Being an engineer is about learning and that learning comes from the experience gained in designing and delivering each release. Together we’ve learned and together we’ve engineered a wonderful product.

    We know there are lots of questions about how to get Windows 7 and when, and of course more questions to come about exploring and using the full set of Windows 7 features. Our Windows Team Blog today has posted a lot of new information and gathered up some important details that we hope will answer your questions. Please check our blog and stay in touch on the in-market developments of Windows 7 there.

    The final few minutes before RTM are a sign-off process where each and every team that contributed to Windows formally commits to having successfully executed the work necessary for the product to be in the release process. We gather one last time (for Windows 7) in the “Ship Room” and a representative from each team signs (literally) and signifies their team’s readiness for manufacturing. We thought we’d share this moment with you here today.

    On behalf of the Windows 7 engineering team we want to thank you very much for your contributions throughout development and your contributions yet to come to Windows 7. THANK YOU!

    Next stop, October 22, 2009!

    --The Windows 7 team

  • Engineering Windows 7

    Engineering Windows 7 for a Global Market

    • 52 Comments

    Microsoft has been a global software company for a long time and has always put a lot of effort into engineering our products for a global customer base.  It is also an area where the engineering is complex—probably a lot more complex than many might think—and one where we are always trying to learn and improve.  Building global software is a responsibility for everyone on the team.  We also have feature teams dedicated to developing both global and market specific features—whether it is font handling or doing East Asian language input as two examples.  We of course have a significant engineering effort that goes into localizing (“translating” is not quite accurate) Windows into nearly 100 languages. Julie Bennett represents the global development and localization teams and she and John McConnell on her team collaborated across the team to author this post that provides an overview of engineering for a global market. --Steven

    Many of the readers of the e7 blog are located outside of the United States or speak a language other than English, so we thought it would be useful to share the international and multi-lingual improvements in Windows 7. Our goal for Windows 7 is to deliver exciting features that benefit users worldwide as well as features that make Windows feel local to every user. Like Windows 7's focus to improve the fundamental scenarios of performance and reliability, we improved our processes to allow us to deliver a great customer experience in every language and every country we serve, including delivery of Windows 7 as close to simultaneously as possible worldwide. This blog entry discusses some of the new features and improved processes that we believe make Windows 7 a great worldwide release.

    Features

    The international features of Windows 7 are pervasive across the system, from such low-level aspects as the supported characters in NTFS file names (now upgraded to match Unicode 5.1) to such high-level aspects as the selection of backgrounds and themes (now including locally-relevant photos). But there are certain features which are intrinsically critical for proper support of the world’s many languages and cultures, and we will describe some of those here.

    Fonts

    Language and writing are at the heart of any culture and thus support for fonts is essential to supporting international users. Windows 7 significantly increases both the range and quality of fonts. We have added fifty new fonts:

     New fonts in Windows 7

    As you might guess from the font names in the above table, many of the new fonts are for non-Latin scripts. In fact, Windows 7 will be the first version of Windows to ship with more fonts for non-Latin scripts than for Latin-based scripts. One major area of improvement is for the languages of India. To the nine (9) fonts for Indian languages that shipped in Vista, Windows 7 adds forty (40) more. Windows 7 will now include multiple fonts (often in multiple weights) for each of the official languages of India.

    Indian font examples

    Aparajita: A New Devanagari Font in Regular, Bold, Italic and Bold-Italic

     

     

    Besides new fonts, we have also improved many of the existing fonts. For example, we have added over two thousand (2,000) glyphs to Consolas, Calibri, Cambria Bold, and Cambria Math. But the most dramatic improvements have been to some of the non-Latin scripts. For example, Windows 7 does a much better job rendering the common Lam-Alef ligature in Arabic (see the illustration below) and in the placement of vowel marks.

    Ligature example

    Left: Lam-Alef Ligture in Vista Right: Lam-Alef Ligature in Windows 7

    Changes to fonts (even clear improvements) are always tricky because of backwards compatibility issues. For example, if a character changes width or position, it may cause existing documents to reflow (repaginate), which is unacceptable. Therefore, whenever we change a font, we must run extensive verification tests against the changes to ensure the font metrics and other tables are unchanged. In the case of the Lam-Alef fix shown above, we discovered that there were existing applications that relied on the (undocumented) order of the glyphs within the old font. These applications would break if we simply replaced the glyphs. The font team worked closely with the international application compatibility team to ensure that changes we made did not affect the order of glyphs within the font, thus providing backward compatibility.

    Font Control Panel

    With so many new and expanded fonts for Windows 7, we also wanted to help users manage their fonts more easily. For the first time in years, we have done a complete overhaul of the font control panel.

    The first picture below shows the font control panel with the large icon view. The most obvious change is that the font icons now convey much more information about the appearance of the font. The content of the icon gives a hint as to the glyph repertoire of the font. The style of the icon matches the style of the font. Non-Latin fonts show typical glyphs from the script for the font to see how it is designed. A more subtle change is that some font icons are faded to indicate fonts that are installed, but hidden. Hidden fonts will not show by default in the ribbon and font dialogs. Users can now use the font control panel to tune the fonts that they regularly use. By hiding fonts they never use, users can simplify choosing the correct font within applications. By default, only fonts supporting languages that can be written with the users installed input locales (keyboard layout plus language) will be shown. For example, users with English and French input locales will see only the Latin fonts, whereas users with the Japanese input method installed will see only the Japanese fonts. Users can override these defaults by right-clicking on any of the fonts in the control panel. Hidden fonts are still installed so an existing application that uses a hidden font will behave identically.

    image

    Font Control Panel with Large Icon View

    The next picture below shows the font control panel with the detailed view. Now users can see much more information about the font. For example, the user can sort fonts by style, whether they are hidden, and information about the creator of the font. Font files generally contain information only in the design language of the font (e.g. a Japanese font might contain only information in Japanese). In Windows 7, we needed a solution that would work for all languages and for all fonts, so we created a hybrid approach that combines information from the font itself with metadata (an XML file that provides the information about the fonts on the system).

    Font control panel detail view

     

    Font Control Panel with Detail View

    Local Packs

    Windows 7 has increased opportunities for personalization. New themes, backgrounds, and sounds make it easy to customize Windows 7 to match your personality. To the extent that our preferences are influenced by our language and location, Windows 7 reflects this with the introduction of Local Packs. Local Packs provide customized Windows 7 visual themes for a specific region. These visual themes contain locally relevant wallpaper images, custom aero glass colors, and regional sound schemes. Windows® Internet Explorer® Favorites and RSS feeds may also be updated when the Local Pack is activated on an end user’s computer. For example, adding and enabling the Local Pack for France will add a market-customized theme for France to the end user’s Personalization control panel and a number of links to useful French Public Sector websites and RSS Feeds to the user’s profile.

    Local Packs

    Customized Themes in the Personalization control panel

    The Local Pack content provides users with seamless local experiences right out of the box. Users are never exposed to Local Packs per se, they just select their Location as normal during Windows Welcome, and appropriate local content is exposed to them based on that setting.

    Users looking for visual themes for other countries, or indeed any other areas of interest, can find them on the Windows Online Gallery, which is accessible via the “Get more themes online” link in the Personalization control panel.

    Other Features

    Other new features include five (5) new locales (bringing the total number of locales supported to two hundred and ten (210)), twelve (12) new input locales, and improvements to sorting for traditional Chinese characters. Also, we have generally updated our system databases to the latest version of the Unicode Standard (5.1). There are also interface improvements that should allow developers to create better globalized applications. Extended Linguistic Services (ELS) is a cool new feature we describe below in the International Timeliness and Quality section.

    Perhaps one of the most important improvements outside the core international features has been in Search, which now recognizes more languages. For example, Windows 7 desktop search now recognizes Russian morphology (the rules for single and plural, tenses, and case). This means that searches for a particular word in Russian will now match not only that exact word, but also the common variations of the word, yielding significantly better results.

    International Timeliness and Quality

    In previous versions of Windows, final delivery of every language to every market took several months. For Windows 7, we changed how we worked on international releases to significantly shorten this delta so that all users worldwide can enjoy Windows as simultaneously as possible. This goal had far reaching implications on how we perform our work as engineers and on how we interact with partners and customers during our public testing phases.

    To understand our approach, we should first explain two important concepts: localization and globalization.

    Localization is the process of adapting the user experience into another language. Beyond the translation of strings, it can also include activities such as resizing dialogs and mirroring icons for right-to-left languages, such as Hebrew and Arabic. Localization bugs, such as the mistranslation of a menu item, are defects introduced during this process.

    Globalization, on the other hand, is the process of producing a product that works well in every country no matter the user interface language setting. A globalization bug may be as simple as showing a UI element in the wrong language and as complex as not properly handling right-to-left scripts. Globalization bugs are inherently more serious than localization bugs as they usually affect many or all languages and often require re-thinking the technical design. In past Windows releases, repairing globalization bugs contributed to the necessity of the long release deltas. For Windows 7 we worked to prevent, find, and fix globalization bugs as early in the development process as possible.

    Pseudo-Localization

    To prevent common globalization bugs, pseudo-localized builds were created. Pseudo-localization is a process that creates a localized product in an artificial language. That language is identical to English except that each character is written with a different character that visually resembles the English character. Except for being entirely machine generated, we create the pseudo-localized builds exactly the same way as we create the localized builds. Because even monolingual US software developers can read pseudo-localized text, it has proven to be an excellent way to find globalization problems early in the development cycle. In the Windows 7 beta, some UI elements were still in their pseudo-localized form, causing some interesting theories about what the meaning might be. We hope we have solved the mystery with this blog post. :-)

     

    Pseudo-loc control panel

    Control Panel Dialog in Pseudo-localized Windows 7

    Pilot Languages

    Beta is always an exciting time for us as it is our first real chance to hear from you about our efforts. We are thrilled that people from over one hundred and thirteen (113) countries downloaded the Windows 7 Beta. With such a large and diverse beta program, we must have highly scalable processes to gather and incorporate your feedback. In Windows 7, we are very excited about some new approaches we took here.

    In the past, localization languages for Windows beta releases were selected for a mix of pragmatic reasons. While this ad hoc approach had benefits, too often we found that serious globalization defects were not reported because they did not manifest in the chosen languages. For the Windows 7 Beta, our priority was to find globalization bugs and therefore we have concentrated on four languages (plus English) that experience has shown are most likely to find specific types of defects:

    • German - Because it contains some very long words, German can reveal dialog size and alignment defects better than other languages.
    • Japanese - With tens of thousands of characters, multiple non-Latin scripts, alternative input method engines, and an especially complex orthography, Japanese is a great way to find defects that affect many East Asian languages.
    • Arabic - Written right-to-left and with contextual shaping (character shape depends on adjacent characters), including this language in the Beta helped us test code paths not exercised by German and Japanese.
    • Hindi - Windows 95 and Windows 98 never supported Hindi and support for this language relies entirely on Unicode. Testing Hindi helps find legacy (non-Unicode) defects that affect all such languages.

    By concentrating on these four languages during Beta, we maximized our chances to find and fix the globalization bugs that affect many languages. This in turn gave us more time to improve the localization of all languages before we release the actual product. The pictures below show two bugs found during Beta that illustrate the advantages of focusing on these pilot languages.

    Example bug

    Globalization Defects Found During Windows 7 Beta

    In addition to our goal of finding globalization bugs via these languages, we also asked some of our OEM customers to provide feedback on the language aspects within their manufacturing processes. Since many of the OEMs are located in East Asia, we also localized Windows 7 Beta for Simplified Chinese, Traditional Chinese, and Korean.

    RC Language Packs

    In part because of the engineering process improvements described above, we were able to deliver more language packs for Windows 7 RC than we have ever been able to do in the past for Windows. For those of you running the Ultimate version of Windows 7 RC, you will have noticed the following thirty-two (32) Language Packs available for download on Windows Update:

    RC Language Packs

    32 Windows 7 RC Language Packs on Windows Update

    One thing we will do differently in the future is to ensure that all languages available at Beta are also available at RC (e.g. not including Hindi for Windows 7 RC). We will correct this for future versions.

    Understanding feedback from around the world

    With Windows 7 beta localized into five languages and globally enabled for hundreds more, we received beta bugs from customers all over the world. We rely on these bug reports to help us improve Windows 7, so we devote much time to reading customer bug reports to determine product issues. Because bugs come from worldwide customers in many languages, we look for ways not only to understand their feedback, but also to address it as quickly as possible. The faster we can understand the issue, the better chance we have of addressing the feedback. As we receive bug reports in all the many languages that our customers speak, this has sometimes posed quite a challenge.

    In the past, we have handled multilingual bug reports using manual processes, where individual bugs were examined and then manually translated one-by-one for appropriate follow-up by the feature team that owned the affected component. This is a time-consuming and error-prone exercise that scales poorly to a program as large and diverse as the Windows 7 beta. In the worst case, valuable international feedback has missed the window to affect the final product, and thus slipped to a Service Pack or subsequent release.

    In Windows 7, by using the language detection API in the new Extended Linguistic Services (ELS), we have been able to automatically detect the language of customer bugs as they are reported. ELS functionality is new for Windows 7 and available to any developer who wants to leverage advanced linguistic functionality in the operating system. Beginning in Windows 7, developers may use ELS to provide language and script detection of any Unicode text, as well as transliteration to map text between writing systems. To use these Windows 7 services and all further services that we will add in subsequent releases, developers need only to learn one simple and unified interface. The ability to detect over one hundred (100) languages is available for all Windows 7 application developers, and we are happy to be able to apply this functionality to triage and handle beta feedback you send us from around the world. We use our own international developer functionality to improve our ability to respond to customer issues globally.

    Once we have detected the language, we take the resulting text and use the machine translation support that is available online from Live Translator. This allows us to translate the text to English to get a sense of your feedback. Our engineers can then search our feedback database for specific features or areas of functionality. This also helps us in our efforts to ensure international application compatibility, as we can learn about potentially problematic international application experiences as soon as customers report them. Machine translation does not provide a perfect translation, but it does allow us to determine which issues might require further investigation. This in turn allows us to hear and respond to customer issues with a much faster turnaround time than we have had in previous releases, which means better quality in Windows 7 when we release it to the world.

    By the end of Windows 7 Beta, we had used this process to translate 35,408 issues and comments submitted using the Feedback tool.

    Putting it all together

    The end result of the work to improve globalization and localization quality is reflected in the announcement that all fully localized releases of Windows 7 will be available within two weeks of the initial release wave with all languages available in October. We hope (and believe!) end users will find the overall quality of these releases to be the best ever.

    36 Windows 7 languages releases available in October 2009

    36 Windows 7 language releases available in October 2009

    In addition to the 36 languages that will be released in October, there will be additional languages available for download as Language Interface Packs (LIPs) onto any Windows 7 edition as part of the Local Language Program (LLP). The LLP is a partnership with governments, universities, and language experts from around the world. (You can find more information on the LLP at http://www.microsoft.com/unlimitedpotential/programs/llp.mspx.) Work on a LIP starts at RTM and continues for many months based on the schedules of our partners. Two (2) LIPs will be available for download when Windows 7 is available in October – Catalan and Hindi. Additional LIPs will become available for download over the following months based on the schedules of our partners. We are happy to have improved the delivery time of the first 38 languages (36 + 2 LIPs) and recognize that future releases are an opportunity to improve further. Creating a track record of dependable release schedules on our part will help everyone around the world plan better for a more unified release timeline.

    More information about Extended Linguistic Services (ELS) and other cool new features of Windows 7 are available on-line on MSDN. In particular, you can download the Windows SDK for Windows 7 and read about what is new in the ‘International’ section. Also, the new Go Global Developer Center on MSDN has a wealth of information about international technologies.

    If you want to send us feedback, please comment on this blog entry or use the Feedback button in Windows 7. We love to hear from you (in any language).

    -- Windows International Team

  • Engineering Windows 7

    Engineering Changes to ClearType in Windows 7

    • 92 Comments

    One of the many passions held by Bill Gates is a passion for reading and so his desire to make reading on PCs a fantastic experience has been an effort ongoing for many years. In the 1998 COMDEX show, Bill Gates unveiled ClearType – hard to believe it was that long ago. Back when it was announced, very few of us had LCD monitors and those that did invested several thousand dollars in one that was 15” and 1024x768 (today one like that costs less than $100). The notions of smoothing and anti-aliasing have been around for many years and are common in the world of typography, animation, and games. ClearType took this to new levels by building on the properties of LCD panels. ClearType was subsequently included in Windows XP and continues in Vista and Windows 7—each release saw changes in the underlying technology, the fonts that support the technology, and the APIs available to developers. It is fair to say that over the years we have learned that there are a set of customers who simply find ClearType rendered screens less than appealing and wish to turn it off. We recognize this and want to make sure we provide the appropriate controls. ClearType is also part of the Windows platform and provides APIs callable and controllable by developers of applications. There is a conventional view that ClearType is a "visual preference" and through this post we want to show how there are elements that are such a preference but there are also elements that are APIs used by applications, just like applications can choose fonts, colors, and other attributes as required.  This post goes into the details of Windows 7’s implementation along with some history and background. Greg Hitchcock is the development lead on ClearType and has worked on it since the start. He’s also one of the most tenured members of the Windows 7 engineering team with only 6 folks having been at Microsoft longer -- Larry is one of them :-)!

    --Steven

    Based on feedback, we want to clarify how font rendering works in Windows 7 and give some background on how we chose ClearType font rendering to be the default in Windows. For those that dislike ClearType and want to change the system default setting to bi-level rendering, as were defaults in Windows Millennium, the quick answer is:

    • Enter Appearance into the start menu search
    • Select Adjust the appearance and performance of Windows from the Control Panel
    • The setting that should be changed under the custom option is: Smooth edges of screen fonts, which should be turned off

    The longer answer, as we will describe in this post, shows that changing the default setting is not as “black and white” as it may seem. As you have noticed, Windows 7 also includes a new ClearType tuner in the control panel which affords fine-grained control over rendering—we’ll talk about that some below as well.

    ClearType

    ClearType is a technology developed to improve both the appearance of font rendering and reading performance on computer displays. As most people spend over 80% of their time on computers reading on the screen, improvements in this area greatly improve the overall experience of Windows. The ClearType technology has continued to evolve and the latest improvements have been made in Windows 7, as discussed in this earlier E7 post.

    In simple terms, ClearType works by using the underlying geometry of colored sub-pixels in the display as if they were full pixels—gaining extra resolution while at the same time using principles of human vision to remove the perception of color artifacts. Further details on the technology and how it uses human visual perception are described here. More specifically, the ClearType technology is optimized for LCD panels with red, green, and blue (RGB) striped sub-pixels that are oriented vertically, although it performs reasonably well on CRT displays (especially those that are aperture grille based) and even LCD panels with horizontally oriented RGB stripes. Although this might seem counterintuitive, through informal studies, we’ve found that about 70% of users prefer ClearType even on these non-optimal displays. Of the 30% who preferred other rendering techniques, their biggest concern with ClearType in these non-optimal cases was the loss of text contrast.

    Other Types of Font Rendering in Windows

    Given the complex world of many display types and a wide variety of users and their visual systems, how did we go about implementing ClearType into Microsoft Windows? Microsoft did not rush headlong into making ClearType the default rendering. The technology was first released in 2000 with the Windows CE product. The Windows CE environment is usually quite controlled in terms of the hardware used, so it was quite easy to verify that ClearType worked properly on each device, and either tune ClearType or adjust the hardware to optimize the onscreen reading experience. The first release of ClearType on the Windows platform was with Windows XP in 2001.

    Bi-Level Rendering

    Example Bi-Level rendering.

    Example of Bi-Level rendering.  Note if your browser scales this image the text will not be correctly represented.

    Prior to Windows XP, two types of font rendering were supported in Windows. The first type of font rendering supported was bi-level rendering, more commonly referred to as “black and white” rendering, but sometimes also called aliased text. With bi-level rendering, two colors represent the font, the foreground color and the background color. This was the first type of rendering supported by TrueType when Windows 3.1 was released, and also the essential method of displaying fonts in bitmap form from Windows 1.0. Bi-level rendering, especially when generated from outline technologies like TrueType, is very difficult to optimize for low screen resolutions. Significant effort needs to be put into the font hinting for TrueType in order to get the best bi-level quality. It can reasonably take a skilled person 6 months to a year per font of hinting time to get this level of rendering detail. That would be multiplied by four for a four-member family. If the character sets are larger, as in some system fonts, it can take even longer.

    Font Smoothing / Grayscale

     Calibri11 Font smoothing example

    The second form of rendering, known as font smoothing, became the default rendering in Windows 2000 and was first released as an option for Windows 95 in the Plus! Pack. Font smoothing is a hybrid grayscale anti-aliasing technique designed to improve the contrast of fonts over traditional anti-aliasing techniques. There are two factors that differentiate font smoothing from more traditional text anti-aliasing.

    First, traditional anti-aliasing works by overscaling the font outline data and then downsampling. Font smoothing uses the same technique, except that it applies font hints prior to overscaling the outline data. Although we don’t have enough space here to fully describe font hinting, I can simplify it enough to say that it often uses a method called “grid fitting” to snap the vertical and horizontal edges of the font outlines so that they are aligned with the pixel grid. In this situation, most horizontal and vertical stems of a font, when overscaled, cover 100% of the underlying pixels, and when downsampled return the text foreground color, which is usually black. Diagonal and round features of the font will not have full coverage of the pixel and thus will return some shade of gray, reflecting the coverage of the underlying pixel. It should be noted that when text displays the “jaggies” (or more formally aliasing) this usually occurs on round or diagonal parts of the glyphs—exactly the areas receiving gray coverage with this method. This way of anti-aliasing is beneficial due to the higher contrast of the stems in the font at a slight cost of some spatial accuracy.

    The second differentiating factor is that the fonts determine the exact size that the font smoothing turns on or off. Most fonts that provide this level of information turn on grayscale anti-aliasing below 9 pixels per em (PPEM.) That is the equivalent of 7 points on a 96 PPI screen. Above 9 PPEM, anti-aliasing is turned off until the main stems of the font are around two pixels wide, which is around 13 to 20 points, depending on the typeface. Once the main stems are two pixels wide, anti-aliasing remains on as the sizes increase. Two pixel wide stems are usually chosen because there is usually enough “backbone” of foreground colored pixels to keep the stem contrast high.  If the font does not have specific sizes for font smoothing, system defaults are used. There are independent defaults for both regular and bold typefaces. So although font smoothing was the default, most fonts, when displaying text at typical reading sizes, would render them bi-level.

    Defaults for Font Rendering

    With the addition of ClearType to Windows XP, there were now three types of font rendering available (Bi-level, Font Smoothing, ClearType). During the time period that Windows XP was being developed there was a clear transition underway from desktop systems with CRT monitors to laptops and desktops with LCD displays. Since this transition was far from complete, we felt that the default value for font rendering in Windows XP should be grayscale font smoothing, the same as Windows 2000. OEM’s who provide Windows XP on their systems could change this default, and in fact, by the time Windows XP SP 2 shipped, many of them had set the default to ClearType. It should be noted that OEMs can always change these settings as part of configuring a PC.

    In Windows Vista, the system’s default font rendering was changed to ClearType. It is important to clearly understand what is meant by default font rendering. In Windows, the default font rendering is the rendering used when the application does not choose an explicit type of rendering. Some have confused this default value to mean that all applications must use this value. This view is inconsistent with the way text APIs worked when introduced in Windows 95’s font smoothing. In GDI, the API for choosing the current font has the rendering type explicitly as input. It is expected that there are situations where the application knows best what type of rendering should be used. For example, in displaying a print preview page with small text, traditional font smoothing might be the best choice for rendering. Likewise, if an application was targeting on-screen reading, it might be best to use ClearType as the rendering for that application. In some situations, like remote terminal services, the application might choose to use bi-level rendering to reduce the bandwidth of text information that needs to be sent to a remote client.

    There are many examples where applications decide one way or another to use rendering other than the system default—just as applications that choose to use different fonts, colors, sizes, or other text attributes.  The most typical example is in applications that wish to have reproducible layout and flow of documents.  By being specific about which way to render text, the applications can be certain of how text will flow across different PCs.  Another common example, as mentioned above, is Print Preview where the ability to properly render representations of higher resolution output, particularly for small text sizes, is much improved.  We recognize that for some it is counter-intuitive that an aspect viewed as a “display” property is something that applications can choose to “over-ride”.  We’ve designed rendering so that the default case is to respect the setting, but applications, including Windows itself, might have elements that require explicit rendering techniques.

    Although each application can make the choice on a per-font basis of which rendering to use, the majority of applications choose the default rendering. Therefore, making the decision to change the default for Windows Vista was not taken lightly. The trends in the hardware displays were strongly showing a rapid movement from CRTs to LCD-based displays as we have shown in earlier blog posts based on the Windows XP and Windows Vista real-world telemetry. Even though there were still CRTs in use, feedback from Windows XP customers was positive on the quality of ClearType rendering on CRTs. After we made the choice, the feedback on the decision to enable ClearType as the default for Windows Vista was overwhelmingly positive.

    Even with the default rendering set to ClearType, there are some scenarios that can change the default. If an OEM is providing Windows on their hardware, they can change the default. In some situations, and this was more common with font smoothing in Windows 95, the hardware may not meet the minimum requirements for the rendering technology. In the case of both font smoothing and ClearType, a minimum of sixteen bits per pixel display resolution is required. (When rendering to an off-screen bitmap in GDI, it is important that it not be the default color depth of 1 bit per pixel if you desire to capture ClearType text.) In some cases, when optimizing for system performance, font smoothing (both ClearType and grayscale) can be disabled. In a similar fashion, using Remote Desktop to connect to another computer or session usually disables ClearType by default.

    Changing the Default Rendering in Windows 7

    Windows 7 maintains the same defaults as Windows Vista. There are several ways for the user to change the default values for font rendering in Windows 7. For those that want the default rendering to be bi-level, the user interface for this selection is in the performance section of the Control Panel. From the root of the control panel you can access it by selecting System and Security –> System –> Advanced System Settings –> Performance (Settings…). An easier way is to enter “Appearance” into the start menu search, and then select “Adjust the appearance and performance of Windows.” The setting that should be changed under the custom option is: Smooth edges of screen fonts, as shown in the figure.

    Performance options showing where to disable smooth screen fonts

    The option of no font smoothing as the default value is considered to be an uncommon setting, so it is a little more difficult to find than other settings. If the user prefers to change the default font rendering selection to the Windows grayscaling anti-aliasing technique described earlier, in Windows 7 that is now done through the ClearType Tuner.

    ClearType Tuner

    The quality of the ClearType text can be optimized for you and your monitor. The ClearType Tuner is a new control panel component for Windows 7. Because there are differences in monitor characteristics and differences between readers’ eyes, there are font rendering options that can only be optimized by a reader looking at text on their monitor. The ClearType Tuner uses various samples of ClearType, presented in the form of an eye-test, to make fine grained adjustments to the ClearType algorithms. Each wizard page tunes a parameter such as monitor gamma (relationship between voltage and brightness), your sensitivity to color artifacts, and your preference for letter heaviness.

    In order to switch between ClearType and grayscale, the setting “Turn on ClearType” on the opening page of the ClearType Tuner can be toggled.

    ClearType text turner

    Either way, the user is taken through the rest of the ClearType Tuning wizard for two reasons; if an application explicitly enables ClearType rendering, it is useful for that experience to be tuned, and some graphics platforms have more fine tuning of the rendering for both gray rendering and ClearType.

     

    Font Design and Font Rendering

    The availability of higher resolution font rendering techniques like ClearType has had a significant impact on the design of fonts for onscreen reading. From the early days of the printing press, as new technologies and printing styles were developed, typefaces were redesigned to take advantage of those technologies. For example, many typefaces still in use today incorporate “ink traps” into the design so that ink would not clog up key features of a glyph. This is an aspect of making specific design choices in the font in order to work the best with the technology. In traditional typeface design, the term font refers to a typeface at a given size. So a 10 point Times New Roman would be a different font from a 24 point Times New Roman. In the days of metal cast typography, each of these sizes were designed by a punch cutter to be optimized for the medium for which they were to be used, often with changes in stem contrast, x-height, or character spacing for a given size. The advent of photo typesetting in the mid-twentieth century was a step backwards in this regard, as it used one size as a type master, and then used optics to scale that master size to any other presentation size.

    Microsoft Windows has taken the more traditional approach to digital outline fonts, and through a combination of font hinting and new typeface design we attempt to optimize each size for the medium for which they were intended. With Microsoft’s initial release of TrueType for Windows 3.1, the traditional typefaces Times New Roman, Arial, and Courier New were used as core fonts. In the creation of these fonts, one master size was chosen for the outline data, usually something around 10 or 12 point, and, similar to the technique used in photo-typesetting, the outlines could be scaled to any requested size for a given display resolution. But, going back to the more traditional ways, each size was carefully examined and changes were made to the basic design through font hinting—including changes to critical features like stem contrast, x-height, or glyph spacing. As earlier mentioned, hinting fonts to be tuned for a low-resolution medium like full pixels on a 96 PPI screen was very time consuming. To help in this process for Microsoft Windows, we commissioned or designed in-house new outline typefaces designs that were optimized for the world of 96 PPI bi-level rendering. These custom fonts include Tahoma, Verdana, Georgia, Trebuchet MS, and even Comic Sans MS. These fonts still needed to be hinted to tune the individual sizes, but because the typeface was designed with the medium in mind, it was a more straightforward process and less time consuming.

    Even with typefaces tuned to the display medium, 96 PPI pixels on a screen are still larger than many of the features we’d like to show in a typeface—and that is where ClearType helps us. Therefore, with ClearType, it made sense to commission a new set of fonts that were optimized for this new medium. Now the existing fonts for Windows still work well with the technology, but this project was an attempt to get the very best design for onscreen reading using ClearType. This led to a new set of fonts that shipped and were tuned for Windows Vista. The ClearType Collection fonts of Calibri, Cambria, Consolas, Corbel, Candara, Constantia, the new user interface font Segoe UI, and the Japanese font Meiryo were designed for this medium. As part of the engineering work on these font projects along with the default setting of ClearType, we decided in the hinting process to do the fine, size-specific hinting only for ClearType, and not for bi-level rendering. This allowed us to focus our efforts on the fine levels of detail and quality for the vast majority of customers.

    ClearType Fonts in Windows 7

    A reasonable question for us to ask ourselves is what is the experience like in Windows 7 when bi-level or hybrid font smoothing is chosen as the default?

    As mentioned earlier, not all applications will choose to render with the default settings. Microsoft Office and Internet Explorer will default in some cases to using ClearType rendering. Some applications that use fonts tuned for ClearType and not bi-level rendering may choose ClearType rendering to maintain the benefits of the font designs. Some applications need higher precision glyph widths like sub-pixel positioning or “natural width ClearType,” and would reflow if they were changed to bi-level or grayscale rendering. Other applications like Adobe Reader have their own built-in text rendering engine that is independent of the Windows graphics platforms. Likewise, platforms like Java on Windows also use their own rendering techniques.

    In some situations with the Windows 7 Explorer, ClearType rendering will remain on so that Segoe UI will keep its optimal design. Changing the system font from Segoe UI to some other font could be problematic, leading to issues like reflowing dialog box entries, missing text due to wrapping, unlabeled buttons, etc. We know many would value global changes to the fonts used by Windows, but to maintain to reliably across resolutions, DPI, and languages to name a few issues means we cannot have total flexibility on the system font settings at this time.

    Given the challenges of turning off ClearType, there are a few mitigations in the fonts to handle some scenarios where ClearType is not available. In the ClearType font Calibri, since it is the default font for Microsoft Office, an unusual technique was used to attempt to improve the quality of the font rendering when font smoothing grayscale was selected. In this case, as opposed to the normal situation where font smoothing was disabled at lower text sizes to remove the blur, at these lower sizes the font enabled grayscale in order to improve the character shape. Also, at a few key sizes, the Calibri font had some bitmap fonts embedded in the outline file. These bitmaps kick in when bi-level rendering is requested. These bitmaps were intended to handle the case where Calibri was being used in a Remote Terminal situation and the default for Remote Terminal was not set to ClearType for performance reasons.

    ClearType Research on Performance

    As mentioned earlier, one of the goals behind ClearType is to improve the performance of reading text on computer screens. We have supported several areas of research looking into measuring this work. The research is done at universities and published in peer-reviewed journals. We have another Microsoft blog, that among other things related to fonts, also describes some of the research work on reading performance. Since those blog entries give more detail and background, we’ll just describe some of the performance highlights.

    • We’ve measured an improvement in word recognition accuracy of 17% using ClearType over bi-level rendering. 
    • We’ve found a 5% speed improvement in reading speed and a 2% improvement in comprehension (this is remarkable) using ClearType over bi-level rendering. A 5% reading speed improvement may sound small, but the cumulative effects can be huge given the amount of time people spend reading.
    • We’ve found the reading speed improvements of 5% continue over longer spans of text, and we’ve found that non-traditional reading tasks like document scanning are about 8% faster with ClearType over bi-level rendering.
    • We’ve found that reading sub-optimal text causes eye fatigue by increasing squinting and decreasing the blink rate. (This may seem obvious, but prior to this work there was no understanding of the physiological mechanisms of eye fatigue.)

    ClearType Research on Rendering Preferences

    Another research question we’ve asked ourselves is why do some people prefer bi-level rendering over ClearType? Is it due to hardware issues or is there some other attribute that we don’t understand about visual systems that is playing a role. This is an issue that has piqued our curiosity for some time. Our first attempt at looking further into this involved doing an informal and small-scale preference study in a community center near Microsoft. This was done with two identical laptops, one with ClearType and one with bi-level rendering. They were placed side by side and participants were asked which version they preferred. This was done with three different samples. Here were the results:

     

    Prefer ClearType

    Prefer Bi-Level

    No Preference

    Sample 1

    33

    1

    1

    Sample 2

    33

    2

    0

    Sample 3

    33

    2

    0

    Average %

    94%

    5%

    1%

    Comments:

    1. 35 participants.
    2. Comments for bi-level rendering:
      Washed out; jiggly; sketchy; if this were a printer, I’d say it needed a new cartridge; fading out – esp. the numbers, I have to squint to read this, is it my glasses or it is me?; I can’t focus on this; broken up; have to strain to read; jointed.
    3. Comments for ClearType:
      More defined, Looks bold (several times), looks darker, clearer (4 times), looks like it’s a better computer screen (user suggested he’d pay $500 more for the better screen on a $2000 laptop), sort of more blue, solid, much easier to read (3 times), clean, crisp, I like it, shows up better, and my favorite: from an elderly woman who was rather put out that the question wasn’t harder: this seems so obvious (said with a sneer.)

    Two other additional preference tests were performed with 28 of 30 participants preferring ClearType to bi-level rendering in one study and another with 52 of 55 participants preferring ClearType. Combining these three tests, we get 113 of 120 participants preferring ClearType rendering over bi-level rendering. It is important to note that in a forced preference test like this, just because someone preferred ClearType, it does not mean that they also don’t like bi-level rendering. It is just a preference towards ClearType.

    Further examination of those who prefer bi-level rendering is of great interest to us and we continue to research this topic and to work with university researchers as well. We expect to see published papers on this topic in the future.

    Future Research

    Going forward, much of our research is in finding ways to make the highest quality text rendering more accessible to everyone. Each visual system has its own characteristics, and just as the ClearType tuner allows us to tune the algorithm for display characteristics, it would also be nice to tune for visual system characteristics. For example, in the United States 7% of the male population is color blind. We believe that we can improve the ClearType algorithm so that text for a colorblind reader is even better than for a reader without colorblindedness. Researching ways to improve text rendering for those with high color sensitivity and lower visual acuity would be just as important for us.

    Conclusion

    Making the screen the best possible place to read is an exciting opportunity for us.  It blends the engineering challenges of working with many display technologies and human visual systems with the artistic challenge of creating a beautiful set of glyphs, where every subtle typographic nuance is important.  In doing this, we need to keep in mind how the science of reading must guide us in making the experience optimal for us—humans. Each rendering technology has advantages and disadvantages for different people; depending on the application in use there are tradeoffs involved. Many of these issues go beyond the ability for people to easily discern choices. Our job is to work hard to provide a great platform for developers as well as tools that people can use to make choices and control how they use their technology. Our goal should be that the out-of-box experience just works. We think that, most of the time, we’ve accomplished this and we also recognize this area is complex and there is a wide spectrum of feedback.

    The team at Microsoft working on these problems has been together since 1990, developing fonts and font-rendering solutions, and working to get a better understanding of the science of reading. The team is made up of engineers, type designers/artists, and psychologists and we work with many other experts throughout Microsoft in attempting to tackle this tough, yet vitally important task. You spend over 80% of the time at the computer reading, so it should be as pleasant an experience as possible. The following article from IEEE Spectrum describes some of the issues we deal with related to the technology, art, and science of text.

    --Greg

  • Engineering Windows 7

    Improving Audio Glitch Resilience in Windows 7

    • 72 Comments

    Delivering excellent audio playback on a PC is one of those “much harder than it looks” technical challenges.  Unlike dedicated audio / video devices, PCs have a lot going on during playback of audio and the playback happens on an incredible array of hardware and software.  Many of you might be familiar with “glitches” that occasionally happen.  In this post, Kristin Carr, a program manager on our Devices and Media team, describes some of the engineering in Windows 7 to improve this area representing the work of a number of folks across the team.  One lesson I learned early in the product cycle is that we don’t say “glitch-free” but rather “glitch-resilient” and hopefully that will make sense as you read this.  --Steven

    Have you ever used your PC to play an MP3 or a DVD? If you answered yes, you’re among the overwhelming majority of PC customers who use their computer for audio and video applications, encompassing everything from watching a movie to playing a game to viewing a YouTube clip. But you may have also had an experience where your audio or video wasn’t quite perfect – perhaps the video was a bit choppy or the audio stuttered. We call this a ‘glitch’ – a perceived discontinuity in your audio or video that interrupts the playback experience. In this blog post, we’ll be focusing on audio glitching: we’ll examine the ecosystem challenges that can cause glitches, and we’ll discuss the work we’ve been doing to improve the Windows 7 experience.

     

    What Causes Glitching?

    In previous posts, we’ve touched on a variety of ecosystem initiatives and challenges that we’ve undertaken for Windows 7, including application compatibility, accessibility, and system performance, among others. Tracing the root cause of audio glitching leads us to a similar place: because Windows runs on a huge variety of hardware configurations and multitasks between dozens of applications, it is challenging to ensure that all of the programs and drivers running on your computer will work together in exactly the way you expect.

    Audio is especially sensitive. In order for you to hear music from your speakers, data needs to be delivered to your audio hardware approximately every 10 milliseconds, or 30 times in the blink of an eye! The challenge is that your PC is usually doing a lot of other things at the same time you’re listening to music, such as streaming that YouTube video or downloading that new song, and many of these other tasks have complex timing requirements as well. As you can imagine, it doesn’t take much – a slow network driver or a graphics driver that requires plenty of CPU time – to prevent your audio from reaching your ears in a continuous fashion.

    So what are we doing to address this challenge? The answer is ‘lots!’ – and the remainder of this blog post will be devoted to discussing these things:

    1. Gathering data in order to characterize the problem
    2. Developing a systematic method to detect and analyze glitches
    3. Getting these tests and tools widely deployed, both at Microsoft and by our Windows partners
    4. Engaging with partners to detect, diagnose and fix glitching issues

    Who Experiences Glitching?

    In studying this during the Windows 7 development cycle, our first order of business was to gather data. We‘d heard reports of audio glitching, but we didn’t know the exact scope of the problem. How often do users hear their audio glitching? Are there certain machines that were worse than others? With these questions in mind, we set out to understand our problem space a bit better.

    We gathered data by using the telemetry infrastructure built into Windows, which allows our users to report back to Microsoft with performance data and other statistics that help us improve the OS. For each machine that opted to contribute data to Microsoft, we measured the number of times that the underlying audio hardware was being starved for data (i.e., when the user might hear a glitch). This data was grouped into “sessions,” each of which represents the data collected on a single machine for a single day or the data collected between machine reboots, whichever is shorter.

    Let’s dive into some of the results. First, let’s look at the overall rate of audio glitching:

    Figure 1: Distribution of Glitch Counts per Session

    Figure 1: Distribution of Glitch Counts per Session

    The chart above shows data from external (non-Microsoft) RC users. Approximately 80% of sessions showed no glitching at all, but 4.3% showed 10 or more glitches, which indicates that audio glitching affects a significant number of users.

    Once we figured out how often glitching occurs, we started looking into why it occurs. First, we broke the data down by laptop/desktop form factor:

    Figure 2: Glitching Likelihood by Form Factor

    Figure 2: Glitching Likelihood by Form Factor

    From this data, we noticed that laptops were almost twice as likely to experience audio glitching. As a result, we’ve made sure to address and target mobile PCs as well as mobile scenarios (for example, playing music while running on battery) for better coverage in our glitching tests and diagnostic tools.

    Next, we looked at glitching likelihood by PC manufacturer:

    Figure 3: Glitching Likelihood by PC Manufacturer (Mfr)

    Figure 3: Glitching Likelihood by PC Manufacturer (Mfr)

    This data showed that certain manufacturers were more likely to be susceptible to audio glitching than others. As a result, we made sure to spread our testing efforts across a wide spectrum of machines and manufacturers. In addition, we are using this data to work with manufacturers to see if we can identify components or specific causes that would result in higher glitch incidents.

    Finally, we looked at glitching on a wide variety of PC models:

    Figure 4: Breakdown of All Glitch Sessions by PC Model

    Figure 4: Breakdown of All Glitch Sessions by PC Model

    In the chart above, we examined all of the sessions that had at least one glitch, and we looked for any correlation with the PC make and model as shown in the table above (actual machine names have been anonymized). The first thing to notice is that Machine A is responsible for more than three times as much audio glitching as any of the other machines on the list. This data confirmed earlier reports of audio glitching on this particular machine, which we traced to a graphics card that shipped in a faulty configuration. As a result, we were able to work with the manufacturer to improve the configuration.

    This chart also helps to show how widespread the issue is. There were hundreds of PC models that showed evidence of glitching – in fact, it seemed difficult to find a single PC model for which audio glitching did not ever occur. On the other hand, most individual machines didn’t show any problems at all. The conclusion that we drew was that audio glitching was not caused by any one hardware configuration, but was dependent on all the different hardware and driver permutations a user could possibly encounter on their machine. It was clear that no machine was immune, and in order to improve the experience, we were going to need a far-reaching, system-wide solution to this problem.

    Developing Tools to Diagnose Glitching

    Once we had data on when and why glitching occurs, the Windows Devices & Media Performance team developed a comprehensive suite of tests that were centered around media playback scenarios and were designed to assess how well a PC performed at that scenario. During media playback, these tests recorded thousands of statistics about the system’s performance, including CPU load, the activity of all components on the system and their corresponding interactions, and whether glitching occurred, among other things. We intentionally covered a huge range of scenarios and configurations, including laptops running on battery power, hardware under stress, hundreds of media content types, and many more. The goal was to exercise each PC in a wide variety of user scenarios in order to uncover and isolate audio glitches.

    In addition, the Devices & Media Performance team created a graphical tool to highlight glitches as well as the CPU activities that occurred before and during an audio glitch, which allows us to quickly diagnose any glitching problems that we uncover. For example, in the figure shown below, we can see a visual representation of when glitches occurred, and we can display related measurements that occurred at the time of the glitching in order to easily pinpoint any suspicious behavior.

    Figure 5: Example Graphical View of Audio Glitch Troubleshooting

    Figure 5: Example Graphical View of Audio Glitch Troubleshooting

    In this case, you can see four audio glitches (shown by red vertical lines in the top panel). Two panels down, we have displayed calls to the CPU that took longer than 3ms (called long ISRs/DPCs). In this example, you can see a direct correlation between audio glitches and long ISRs and DPCs, which are procedure calls executed by the operating system that have the potential to hog the CPU and produce audio glitches. From here, we can track down the components responsible for these calls in order to reduce or eliminate the glitching. This figure shows additional information than what we used to diagnose the particular problem discussed above; however, this information and the many other measurements are available to diagnose other glitches and media performance issues from across a wide range of sources.

    Putting the Tools to Work

    Armed with these tests and tools, our next step was to deploy them on as many systems as possible. As part of this effort, we are participating in a Windows-wide initiative to help OEMs test their PCs at or before ship time. Hundreds of OEM machines get shipped to Microsoft for use in our Windows lab where we run thousands of tests in order to validate and ensure the best user experience. What this means is that if we notice that a particular machine or configuration might be susceptible to glitching, we can work with the OEM to try to fix the problem before the consumer ever sees their new PC.

    By running these tests and analyzing the results with our new tools, we’ve been able to find hundreds of potential issues that would result in audio glitches. In some cases, this analysis resulted in changes to the Windows code. In other cases, we have identified components developed by our partners that can lead to audio glitching.

    Engaging with Windows Partners

    Since the issues we identify with these tools often involve components from many different partners, an important aspect of this work is engaging with these partners. Until now, it has been almost impossible for manufacturers to know how their components will affect the system as a whole, but by making these tests and tools available, we are attempting enable these partners to see how their components interact and what the final impact on users will be.

    As part of this effort, we have been working to ensure that our partners can take full advantage of these new tools and tests. We’ve talked with OEMs, ODMs (original design manufacturers, who traditionally assemble the PC for the OEM), hardware manufacturers, and software vendors. We’ve given presentations and tutorials, written whitepapers, and held video conference workshops. Our goal has been to make it as easy as possible to create glitch-resilient software and hardware.

    In summary, this effort includes:

    1. Sharing audio glitching telemetry data with our partners. Our partners have had very little concrete data on the prevalence of audio glitching. With the data we are now collecting, we can help them to diagnose problems and improve their products.
    2. Running our suite of audio and video performance tests on the hundreds of machines that OEMs send us and communicating the results to our partners. By assessing as many systems as possible and providing these results, we begin to tackle the causes of audio glitching.
    3. Providing the tools and support that enable our partners to understand how their components are interacting with everything else on a PC and enable them to more easily address the subtle issues that can result in audio glitching.

    What’s Next

    Ultimately, we and all of our Windows partners share a common customer (you!); by working with our partners, calling attention to these issues, and providing more insight into the root causes of audio glitching, we are continue to improve the audio experience for everyone.

  • Engineering Windows 7

    Creating, Saving, Sharing Themes in Windows 7

    • 70 Comments

    When we posted the new "inbox" desktop backgrouns, the reactions showed just how personal, personalization can be.  Building on that theme of personalization (pun intended), we wanted to share some of the work we did on themes in Windows 7.  We’ve shared data about customization in previous releases of Windows and this post builds on that.  This is also an area where we know there is very broad spectrum of desires (needs) for personalization and we definitely had to balance the engineering and design efforts.  I’ve received mail from many folks wanting to personalize (tweak) nearly every pixel on the screen—from border width, to title bar transparency percentage, to height of taskbar, to color/size/location of the close button (I’ve received each of these in email more than once).  At the other end are customers who are enormously happy when they can easily change the background picture and color scheme, and many do.  With Windows 7 we picked a group of settings that we believe represent the most satisfying settings to broadly personalize, and would also provide the most robust platform that maintains application compatibility, and made those easy to change.  In addition we wanted to make it easy to package up those settings so you could save and share them.  We think of this as the start of bringing robust personalization (and customization) to a broader set of customers.  Katie Frigon, a program manager on the core user experience team, authored this post. 

    --Steven

    PS: Things are "slowing" down as we have talked about in how we will get to the RTM milestone.  You might have noticed the announcement we made today in Asia regarding Windows 7 release and availability. Thank you to everyone who has been using the RC and helping to reach the next milestone.

    Creating and Sharing Windows 7 Themes

    In early builds, you may have noticed that Windows 7 includes a variety of themes that change your desktop background, window color and sounds with a single click. These themes are located in the Personalization Control Panel which is easily accessed from the desktop context menu.

    Personalization Control Panel

    Personalization Control Panel

    Desktop Context Menu

    Desktop Context Menu

    In the RC, you can see a number of new themes, for example the “Architecture” theme. This theme is comprised of six architectural photos which cycle on the desktop background, a complementary “Twilight” window color and the “Cityscape” sound scheme which was inspired by the sounds of an urban jazz club.

    Elements of themes in Windows 7

    A theme is a coordinated set of Desktop Backgrounds, Window Colors and Sounds.

    Windows provides a set of themes in box and if customers want more there is a prominent link in the Control Panel to get additional themes online. This link takes you to the Windows Online theme gallery where Microsoft provides additional content including a variety of international themes.

    Personalization Control Panel: Get more theme online link

    Personalization Control Panel: Get more theme online link

    Creating a theme

    While our customers enjoy the content we’ve provided both in the box and online we also know that they enjoy and desire the option to customize their PC’s even more than choosing a theme. Windows 7 continues to be about your PC reflecting you and what you do, as well as putting you in control of that experience. So, if you do want to go beyond the options in the box and on the web, it is easy to create and share your own themes. Creating your own theme can be as easy as just changing your desktop background image while keeping the rest of the settings the same or you can change all the settings one-by-one.

    From our Beta Customer Experience Improvement Program data we see that customers are changing and creating themes. We also see many users changing the different settings, the most popular being desktop background:

    Figure 1: Break out of theme type

    Figure 1: Break out of theme type

    Note: Only 15% of the beta users kept the default theme. 77% of the beta users created a custom theme by changing one or more elements of the inbox themes.

    Figure 2: Percentage of Beta users selecting each theme component in a session

    Figure 2: Percentage of Beta users selecting each theme component in a session

    Note: 35% of beta users who opened the Personalization CPL clicked on “Desktop Background”.

    Now let’s look at how you can change the different settings and save a custom theme. To start, you can change any of the theme settings by starting in the Personalization Control Panel.

    Personalization Control Panel: Click on the items beneath the theme gallery to change your theme settings.

    Personalization Control Panel: Click on the items beneath the theme gallery to change your theme settings.

    Let’s start with the desktop background control panel. This control panel has been enhanced for Windows 7 to support the pictures library and the new desktop background slideshow capabilities. If you choose the “Pictures Library”, we will show all of the pictures in that library including subfolders. All you need to do is select more than one photo to have them cycle as your desktop background slideshow. In this example, I have selected some of my favorite photos from a recent trip to Hawaii to use as my desktop background.

    Desktop Background Control Panel: Windows 7 adds support for libraries and desktop background slideshows. I’ve selected the pictures I want to use in my theme.

    Desktop Background Control Panel: Windows 7 adds support for libraries and desktop
    background slideshows. I’ve selected the pictures I want to use in my theme.

    When personalizing your PC, you might want to go further than just changing your background. Changing your window color or sound scheme is simple, just click on the items beneath the themes gallery. We provide 16 window colors to choose from and the ability to pick a custom color as well. New to Windows 7, we include 14 sound schemes with the OS inspired by a variety of regional music traditions, so you have plenty to choose from. If that isn’t enough, you can include your own sounds if you want.

    Windows Color and Appearance

    Sound control panel

    Window Color and Sound Control Panels: It is also easy to change your window color
    or pick from 14 diverse sound schemes.

    After you change the desktop background, window color or sound scheme, you will notice that we have created a new “unsaved theme” that contains your changes. Your unsaved settings will be preserved when trying other themes in the gallery so you can get back to your most recent customizations. If you are happy with your personalization settings, you can ensure that they are always available in the themes gallery by clicking “Save theme”.

    Personalization Control Panel: I clicked "Save Theme" to ensure that my current personalization settings will always be available in the themes gallery.

    Personalization Control Panel: I clicked "Save Theme" to ensure that my current
    personalization settings will always be available in the themes gallery.

    Sharing themes

    After saving your personalization settings for your own use, you might want to share these settings with friends and family or bring the settings to another PC. Windows 7 allows you to share your themes by right-clicking on your current theme and selecting “Save theme for sharing”. After specifying a name and folder destination for your theme, Windows will collect all of your custom desktop background images, sounds, mouse pointers and icons into the new .themepack file format that can be applied on another computer running Windows 7.

    Personalization Control Panel: When I’m ready to share my theme with Friends, Family and on the Web, I right-click on my current theme and select “Save theme for sharing”.

    Personalization Control Panel: When I’m ready to share my theme with Friends, Family and on the Web,
    I right-click on my current theme and select “Save theme for sharing”.

    Sometimes after I take a fun vacation I like to create a theme that reminds me of the trip. To do this I select the best photos from the trip to rotate as my desktop background and then pair those with a matching window color and Windows 7 sound scheme that best matches the mood of the trip. After I save as a new .themepack I can either share this file via Windows Live to friends and family or use it from another PC in my house via Homegroup.

    Sharing with Windows Live

    Since all of the personalization settings are now contained in a single file, it’s easy to upload the theme to Windows Live Skydrive and post a link to the theme on a Windows Live Spaces blog. Once my friends and family upgrade to Windows 7, they will be able to download themes from trips that we went on together so they can enjoy my photos on their desktop background.

    Windows Live: I can also upload my theme to my Windows Live Skydrive and add a link to the theme on my blog.

    Windows Live: I can also upload my theme to my Windows Live Skydrive
    and add a link to the theme on my blog.

    Sharing via Homegroup

    In Explorer you can create a themes Library. Then from another computer in a Homegroup you just browse to the shared location and click on the desired theme to apply those settings with a single click.

    Explorer: I created a themes library on one of my PC’s and shared it with my Homegroup. From another PC in the home, I can click on any of these themes to apply them.

    Explorer: I created a themes library on one of my PC’s and shared it with my Homegroup.
    From another PC in the home, I can click on any of these themes to apply them.

    But wait…there’s more.

    One additional way we’ve added value with Windows7 themes is by capitalizing on the growing popularity of RSS photo feeds to share photos. Enthusiasts can create a theme where the desktop background slide show points to an RSS photo feed. For example, my sister lives across the country and we only see each other about once a year. An easy way for me to keep her up to date on my family is to send her a Windows 7 theme which points to my RSS photo feed. When I upload new photos they will appear on her desktop automatically.

    Because there are a few different ways to create an RSS photo feed, the process to include an RSS photo feed in a Windows 7 theme will only work if your RSS photo feed links to the high resolution photos using the “enclosures” method. The feed should only reference picture formats such as JPEG or PNG. Due to this limitation themes must be created manually when including an RSS photo feed.

    So, to create one of these themes you can follow these steps:

    1. Download the template from MSDN.
    2. Open the template using Notepad.
    3. Replace {themename} with the name you want to appear in the Personalization Control Panel themes gallery.
    4. Replace {rssfeedurl} with the full path to your compatible RSS photo feed.
    5. Save the changes as a file with the “.theme” extension.

    It is ready for you to share! Send the file via email, etc. to your friends and family.

    Photo sharing sites can also offer these Windows 7 RSS photo themes which provide more ways to connect their customers.

    Looking ahead

    Themes in Windows 7 make it possible for you to make the PC reflect you. Beyond my example of sharing personal photos as a theme, we hope that users will find new and creative ways to use themes in Windows 7. Wedding photographers can include Windows 7 themes in the packages they deliver to their clients, Artists can create themes that showcase their creative style and businesses can create themes that promote their brand. We look forward to seeing how you are using themes to Personalize these aspects Windows 7.

    --Katie

    PS: We've posted some additional themes you can download and use on http://windows.microsoft.com/en-US/Windows7/Personalize which is the US English link from the Themes control panel.

  • Engineering Windows 7

    Safeguarding Windows 7 – Parental Controls

    • 37 Comments

    As you can imagine, our team is quite busy working through this next phase of Windows 7.  We definitely appreciate the millions of downloads and installs of the Windows 7 RC.  Things are going as we expect at this point.  On a personal note, I wanted to thank all the folks who have been sending me mail.  I’ve received a lot of kind words and support regarding the RC and quite a few people saying “hurry up and just release it”.  We outlined the steps we’re taking for this next milestone and aren’t going to rush things.  We’ve got a lot of work for sure!  Not that I’m counting, but I just crossed over 3,000 emails sent via the contact link in this blog.  While I haven’t answered all of them, I’ve done the best I can, and appreciate each and every exchange. 

    Windows 7 includes a set of features for safeguarding your PC when used by children.  This post is by Vladimir Rovinsky, a program manager on our Safety Team, who details the features in Windows 7 specifically around Parental Controls.  This work is in addition to the safety of the OS itself and of course the features built into Internet Explorer to provide safety and security while browsing.  You might also want to check out Windows Live Family Safety which is part of Windows Live Essentials (http://download.live.com) which provides even more for safety and parental controls.  --Steven

    Today, children are exposed to digital hazards more easily than any time in the past. Especially with the help of powerful search tools, convenient social networking applications, low cost tools and services for publishing videos and photographs, the web is awash with content that’s inappropriate for children, and full of people that parents want to bar from contacting their children.

    These digital hazards are accessible to children through a variety of applications, including web browsers, instant messaging applications, media players, games, and email applications. Many of these applications have attempted to offer parental control features. However, they offer this functionality through variety of user interfaces, locations and include varied terminology. The duplication and inconsistency of parental control settings management can make it difficult for parents to maintain the correct settings across multiple applications.

    Windows Vista Parental Controls provided a framework to solve these problems by offering:

    • A single, central location in the Windows Control Panel to configure and manage parental control settings and activities;
    • Built-in restrictions on web content and file downloads, time spent on the computer, application usage, game usage as well as the ability to log and view user activity.
    • The Windows Parental Control platform public application programming interfaces (API) which expose in-box restriction settings and logging functionality to any application. For instance, Internet Explorer and Mozilla Firefox 3.0 are using these APIs to determine if file downloads should be blocked for a user.
    • Integration with the User Account Control (UAC) to enforce standard user accounts for parentally controlled users; promotion of best practices for keeping kids safer on a Windows computer; for instance, encouraging the creation of separate standard accounts for managed children, password creation for parent accounts (administrators), etc.

    To get a quick demo of Windows Vista Parental Controls in action, check out this video.

    For more information about developing software for Windows Vista Parental Controls, see Using Parental Controls APIs.

    Key Design Decisions for updates to Windows 7 Parental Controls

    Responding to customer feedback and evolving nature of the web and challenges it poses to the parents, we strive to provide families with flexible and effective safety features. Our efforts for the Windows 7 release of Parental Controls were focused on the following objectives:

    1. Further developing the extensibility of the Parental Controls platform to enable third-party developers to create richer Parental Control capabilities that integrate well with Windows 7 Parental Controls.

    The Windows 7 Parental Controls platform was modified to allow multiple independent providers of Parental Controls functionality to be installed on the system and augment or fully replace the parental controls provided by Windows 7. Windows Vista allowed partial replacement of Windows Parental Controls; the web filter was replaceable. In Windows 7, in addition to the web filter components, the entire Windows 7 Parental Controls user interface can be replaced by third-party providers. The underlying enforcement of the offline restrictions will still be performed by Windows Parental Controls platform. Allowing a third party provider to replace the entire Windows Parental Controls user interface creates a consistent user experience that seamlessly combines existing Parental Controls functionality with the new ones introduced by the third-party provider.

    The Windows Control Panel Parental Controls screen still remains the central location and launching point on Windows 7 for Parental Controls functionality regardless of whether it is provided by default (system) or by a third-party provider.

    2. Removal of web content restrictions and activity viewing functionality from default (system) Parental controls provider and reliance on Windows Live or third-party providers for these capabilities.

    The web is changing much faster than we can update the Windows operating system. For example, when Vista was released Social Networking was barely known. Now it has a thriving web presence. We need to keep web focused parental controls up with innovation. Because of this, we have moved them into Windows Live.

    Web filtering and activity viewing capabilities can be more efficiently provided by Windows Live or a third-party solution that implement web based delivery of this functionality. For instance, Microsoft’s Windows Live Family Safety free application provides web content filtering, file downloads restrictions, and activity monitoring. It also provides online contact restrictions for children using Windows Live online applications (Windows Live Hotmail, Windows Live Messenger, etc).

    You can learn more about Windows Live Family Safety solution here.

    More information about Windows 7 changes to the Parental Controls platform can be found here.

    Windows 7 Parental Controls User Interface Changes.

    Elements new to Windows 7 Parental controls top-level screen can be seen on the following screen shot:

    Figure 1    Windows 7 Parental Controls screen

    Figure 1 Windows 7 Parental Controls screen

    1. The Additional controls section allows users to select a provider for additional controls such as web filtering, activity reporting, online contact management, etc. When a third-party controls provider’s installed on the computer, the screen displays the Select a provider drop down box that shows the currently selected (active) provider. A description of the provider’s functionality, as supplied by the provider, is shown below the drop down.
    2. When the user account is selected by clicking user’s name or picture, the provider configuration for the user is launched. The provider can take over the default configuration UI for the in-box offline restrictions.  Optionally, provider generated status strings for user accounts are displayed under user account pictures.
    3. An Icon supplied by provider is shown in the upper right corner of the screen.

    Additional control providers can still rely on the default’s (system) provider UI for the configuration of in-box offline restrictions. If a provider chooses to do so, the User Controls screen can be presented to configure a user’s Parental Controls settings.

    If an additional provider is selected and configured, the following new user interface elements are shown on the Windows 7 User Controls screen:

    Figure 2  Windows 7 User Controls screen. Additional controls provider is installed and configured.

    Figure 2 Windows 7 User Controls screen. Additional controls provider is installed and configured.

    1. More Settings allows direct access to the currently selected provider’s functionality.
    2. Web Restrictions allows access to the currently selected provider’s functionality.

    Windows Parental Controls settings and Vista to Windows 7 upgrade

    If a Windows Vista PC which has parentally managed user accounts with enabled web filtering restrictions is upgraded to Windows 7, parents (administrators) are warned during the upgrade as well as when opening the Windows 7 Parental Controls screen, that web filtering and activity reporting functionality is not part of Windows 7 Parental Controls.

    Figure 3  Windows 7 Parental Controls screen. Some users have web filtering restrictions. No additional provider is installed.  

    Figure 3 Windows 7 Parental Controls screen. Some users have web filtering restrictions. No additional provider is installed.

    Windows Vista Parental Controls settings (including web filtering and activity logs information) are preserved unchanged when upgrading from Windows Vista to Windows 7. Although web filtering settings and activity logs information are not used by Windows 7 Parental controls, their preservation allows third-party provider to honor these settings.

    As you start using Windows 7, we hope these changes to Parental Controls capabilities will make you feel more confident and in control of how your family members are using computers and experiencing the web.

    --Vladimir

  • Engineering Windows 7

    Media Streaming with Windows 7

    • 141 Comments

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

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

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

    Not Just for the Techie

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

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

    Each of these scenarios will be discussed throughout this post.

    Configuring the stream options in Windows Media Player

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

    Libraries shared between Media Player and Media Center

    Media Center

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

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

    Who Can Access My Shared Media Libraries?

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

    Changing homegroup settings

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

    Enable streaming.

    Allowing devices to share media from Media Player

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

    Restricting sharing to specific devices.

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

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

    Choosing the Play To device in Media Player

    Choosing the Play To device from Explorer

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

    Allowing remove control of the player

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

    Compatible with Windows 7 logo

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

    Play To remote control window.

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

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

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

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

    Using Xbox 360 for media playback

    Using Xbox 360 for media playback

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

    Internet Access to Home Media

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

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

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

    Enabling internet access to home media.

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

    Specify the network to be a home network

    Reliability - Network Connection Requirements

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

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

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

    Media Formats

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

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

    Table of media format support.

     Table 1: New Decoders in Windows 7

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

    Windows Experience Index

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

    Digital Living Network Support in Windows 7

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

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

    DLNA acronym table

    Table 2: DLNA Device Profiles Supported by Windows 7

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    -- Scott, Tim and the Devices & Media team

  • Engineering Windows 7

    Our Next Engineering Milestone

    • 98 Comments

    Back in January we released the Beta and updated you on our overall engineering process that will get us from Beta to the Release Candidate.  Today, downloading of the Release Candidate started and we’re already seeing a lot of installations and a lot of excitement.  On behalf of the team, I want to extend a thank you for all of the millions of people who have been running and testing the Beta who have helped to make the Release Candidate possible.  The feedback we have received, through all the mechanisms we have blogged about, has been an incredibly valuable part of Engineering Windows 7.  We continue to be humbled by the response to Windows 7.  Thank you!

    This post is about the path from RC to what we call RTM, release to manufacturing.  RTM is not one point in time but a “process” as from RTM we enable the PC manufacturers to begin their processes of building Windows 7 images for new PCs, readying downloads for existing machines, and preparing the full supply chain to deliver Windows 7 to customers.  Thus RTM is the final stage in our engineering of Windows 7, but the engineering continues from RTM until you can purchase Windows 7 and Windows 7 PCs in stores at General Availability, or GA.

    The path to RTM starts with downloads of the RC.  The RC is “done” and what we are doing is validating this against the breadth of the ecosystem and with partners.  It means, from our perspective, we have run many tests many times and are working to understand the quality of the release in a breadth sense.  We’re all familiar with this as we have done this same thing as we went from pre-Beta to Beta and from Beta to RC.  The primary difference with the RC is that we will not be changing the functionality or features of the product at this point—that’s the sort of thing we’ll save for a future release.   We’ve gotten tons of feedback on design and features and shown how we have digested and acted on this feedback throughout many posts on this blog.   We know we did not do everything that was asked, and we have also seen that we’ve been asked to do things that are tricky to reconcile.  We hoped through the dialog on this blog that we’ve shown our commitment to listening and balancing a wide variety of inputs, and how we have thought about the evolution of Windows.  

    What sort of feedback are we looking for in the RC?  We are primarily focused on monitoring the behavior of the product through the telemetry, and of course making sure we did not introduce any regressions in any dimension from Beta quality.  One of the things we have done since Beta has continued to beef up telemetry—we’ve put in additional monitoring points in many systems.  We’re particularly interested in seeing what devices are installed, drivers that are required, and overall system performance.  We have telemetry points that monitor the UI responsiveness of the Start Menu, Internet Explorer (recently posted), Boot, Shutdown, Resume, and across all subsystems.  Of course in the final product, this telemetry is optional and opt-in, and it is always private. 

    There are a series of specific types of reports that we are keeping an eye out for that would constitute changes we would make to the code between now and RTM.  Some of these might include:

    • Installation – We have significant telemetry in the setup process and also significant logging.  Of course if you can’t set up at all that is something we are interested in and the same holds for upgrades from Windows Vista.  For the “enrolled” beta programs we have a mechanism to enlist a connection to Microsoft for these issues and for the broad community the public support groups are monitored. 
    • Security issues – Obviously any vulnerability is a potential for something we would fix.  We will use the same criteria to address these issues as we would for any in-market product. 
    • Crashes and Hangs – We are monitoring the “crash” reports for issues that arise that impact broad sets of people.  These could be Windows code, drivers, or third party software.  This information streams “real time” to Microsoft and we watch it very carefully.
    • Device installation and compatibility – When you download a driver from Windows Update or install a driver via a manufacturer’s setup program this is a data point we collect.  We’ve had millions of unique PnP IDs through the Beta.  We also receive the IDs for devices that failed to locate drivers.  We are constantly updating this web service with pointers to information about the device (driver availability, instructions, etc.)
    • Software installation – Similar to devices, we are also monitoring the installation process of software and noting programs that do not complete successfully.  Again we have the mechanism to help move that foreword and/or introduce compatibility work in the RTM milestone.
    • Servicing – We will continue to test the servicing of Windows 7 so everyone should expect updates to be made available via Windows Update.  This includes new drivers and will also include patches to Windows 7.  Test Updates will be labeled as such.  We might also fix any significant issue with new code as well.  All of this in an effort to validate the servicing pipeline and to maintain the quality of the RC.
    • New Hardware – Perhaps the most important category is making sure that we work with all the new hardware being made as we all use 7100.  Our PC Manufacturing partners and Hardware partners are engineering new PCs and these are combinations new to the market and new to the OS.  We’re working together to make sure Windows 7 has great support for these PCs and hardware.

    All of the feedback will be evaluated and whether the issue is with Windows itself or with hardware, software, or OEM partner code we will work closely across the entire ecosystem to do what is necessary to deliver excellent fully integrated PCs.  This goal is more important than anything else at this point.  The depth of this work is new for the team in terms of spending engineer to engineer time across a broad range of partners to make sure everyone is ready together to deliver a great PC experience.

    Overall, while many have said that the quality of the Beta was on par with past RCs (remember how some even suggested we release it as final!), we are working to do an even better job with Windows 7.  We think we have the tools in place to do that. 

    While the RC itself was compiled about 2 weeks ago, it takes a bit of time to go through the mechanics of validating all the ISOs and images that are released.  In the meantime we continue doing daily builds of the product.  The daily builds are incorporating code changes to address the above types of issues that impact enough customers that on balance the code change is more valuable than the potential of a regression.  Throughout this process, every change to the code is looked at by many people across development and test, and across many different teams.  We have a lot of engineers changing a very little bit of code.  We often say that shipping a major product means “slowing everything down”.  Right now we’re being very deliberate with every change we make.

    The RTM milestone is not a date, but a process.  As that process concludes, we are done changing the code and are officially “servicing” Windows 7.  That means any subsequent changes are delivered as fixes (KB articles) or banked for the first service pack.  Obviously our ability to deliver fixes via Windows Update has substantially changed the way we RTM and so it is not unreasonable to expect updates soon after the product is complete as we have done for both Windows XP and Windows Vista. 

    Between now and the RTM milestone we will make changes to the code in response the above inputs.  We are decelerating and will do so “gracefully” and not abruptly.  We do not have a “deadline” we are aiming to meet and the quality (in all dimensions) of the product and a smooth finish are the most important criteria for Windows 7.  In addition, we have a lot of work going on behind the scenes to build Windows 7 in nearly 100 languages around the world and to make sure all the supporting materials such as our Windows web site, SDK, resource kits, and so on are ready and available in a timely manner.

    Once we have entered the RTM phase, our partners will begin to make their final images and manufacture PCs, and hardware and software vendors will ready their Windows 7 support and new products.  We will also begin to manufacture retail boxes for shipment around the world.  We will continue to work with our enterprise customers as well and based on the RTM process the volume license products will be available as well.

    Delivering the highest quality Windows 7 is the most important criteria for us at this point—quality in every dimension.  The RTM process is designed to be deliberate and maintain the overall engineering integrity of the system.  Many are pushing us to release the product sooner rather than later, but our focus remains on a high quality release.

    Ultimately our partners will determine when their PCs are available in market.  If the feedback and telemetry on Windows 7 match our expectations then we will enter the final phases of the RTM process in about 3 months.  If we are successful in that, then we tracking to our shared goal of having PCs with Windows 7 available this Holiday season. 

    --Steven and Jon

  • Engineering Windows 7

    Support and Q&A for Solid-State Drives

    • 138 Comments

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

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

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

    Random Reads: A very good story for SSDs

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

    Sequential Reads and Writes: Also Good

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

    Random Writes & Flushes: Your mileage will vary greatly

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

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

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

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

    Random Writes & Flushes: Why is this so hard?

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

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

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

    Performance Degradation Over Time, Wear, and Trim

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

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

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

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

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

    Windows 7 Optimizations and Default Behavior Summary

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

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

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

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

    Frequently Asked Questions

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

    Will Windows 7 support Trim?

    Yes. See the above section for details.

    Will disk defragmentation be disabled by default on SSDs?

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

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

    Will Superfetch be disabled on SSDs?

    Yes, for most systems with SSDs.

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

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

    Is NTFS Compression of Files and Directories recommended on SSDs?

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

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

    Does the Windows Search Indexer operate differently on SSDs?

    No.

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

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

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

    Does Media Center do anything special when configured on SSDs?

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

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

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

    Do RAID configurations make sense with SSDs?

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

    Should the pagefile be placed on SSDs?

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

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

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

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

    Are there any concerns regarding the Hibernate file and SSDs?

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

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

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

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

  • Engineering Windows 7

    A Little Bit of Personality

    • 89 Comments

    Greetings!  Based on the data we’re seeing we know a lot of folks on MSDN/TechNet/Connect are probably busy using the RC (Release Candidate) for Windows 7.  Thank you!!!  And of course many folks are looking forward to downloading the RC and using it as we expand the downloads—we’re looking forward to the participation and seeing the data that will help us validate the RC.  We’ve talked about making sure that you are “in control” of Windows 7 and one of the ways that people are in control of their PC is to personalize the experience.  With the RC you’re going to see some of the new personalization “elements” in Windows 7.  In this post, Denise Trabona and Samuel Moreau of our product design team provide a behind the scenes look at some of the work.  Be sure to check out the links below the images as you can see a lot more work by these talented artists.  Note, these are just thumbnails for this post so be sure to enjoy the full screen images in the RC.  --Steven

    PS: Just a reminder, that just as with the pre-beta and beta we’ll be testing out Windows Update and the system for doing patches and updates.  So along with new drivers you might also see some other updates flowing through the system. 

    One of the most exciting parts of engineering Windows 7 has been the wide variety of work that gets done over the course of a full product cycle. As evidenced by the variety of topics just in this blog, one can see that we are hard at work at all levels of the product. For fun, we thought folks might enjoy hearing some of the story behind the new personalization work in Windows 7.

    As some folks have noticed, we are unveiling some new personalization content (wallpapers, glass colors and sounds schemes) in the RC build which allows people greater flexibility to personalize their experience. One thing we know is that Windows users love to express themselves by changing the desktop background and like many past releases, Windows 7 includes content in the box that allows you to begin customizing your experience immediately.

    A picture speaks a thousand words

    In developing the personalization features, we knew that we wanted great content for people to express their personal style. Because the desktop background is such a vibrant surface, we wanted to focus on providing quality content that demonstrated how creative people could be with this feature. When folks send us screenshots using the feedback button, we are regularly inspired by the rich diversity and personality of the wallpapers that people choose.

    As we thought about how we wanted to approach personalization in Windows 7, we knew one way was to honor our lineage. In the past photography has been featured heavily Windows. Some of that photography has been quite beautiful and has become a proud tradition we wanted to maintain. In addition, we also wanted to explore new territory and expand our visual palette. In the realm of photography, we kept a theme focused on landscape photography which is our tradition, but added new themes for architecture and nature. Much of the this imagery is from our stock imagery partners, but we also had the good fortune to work with a talented local photographer named Will Austin, who has photographed all over the world on many subjects with an emphasis on architecture. Will’s photos provide a little bit of the local flavor of the Seattle area that we are proud to call home.

    image

    image

    Raising the bar of inspiration and delight

    With the photography covered, we tried to broaden our coverage to include additional images that would inspire, delight and invigorate people’s imaginations. We wanted to stretch into some new content that felt unique, timely, and with a distinct point of view. Our goal was content that balanced the timelessness of great photography with graphical illustrations that are energetic, modern, and fresh. On top of it all it was also important to achieve a rich variety in the illustrations to appeal to different tastes, genders and ages, color ranges from quiet to loud, and from large compositions to small and detailed.

    Inspired by our neighbors in Zune, we worked with an agency called 72 and Sunny to search for illustrators around the world to create one-of-a-kind art work for you to have in Windows 7. In the process of looking through tons of samples, we sought a group of artists whose styles seemed both incredibly varied, to cover the broad diversity we were after, and maintained a common thread that we felt was applicable to the overall tone we were striving to achieve. Then began the fun part, with little more than some simple guiding words (light, energetic, inspiring, optimistic, etc.), the artists went off with a blank canvas to create concept sketches of their original pieces.

    Iterate and refine

    We still remember the first chance we got to review the artist’s initial sketches and concept work, and right from that moment, we knew that these images were going to be a lot of fun. The next step was to iterate back and forth a few times to make sure certain goals were achieved and get little details just right. For example, a couple of things that were important to us were how the image flowed under the new task bar and striking the right balance between visually compelling, and not too distracting when it came to finding that important file on your desktop. It’s tricky to find the right balance and we were fortunate to have an amazingly talented set of artists and our friends at 72 and Sunny to work with on this project.

    Windows is for the whole world

    Finally, we wanted to recognize the global audience of Windows by seeking out illustrators with varied backgrounds and styles with the intention of representing and appealing to people all around the world.

    With that, we are honored to introduce the amazingly talented artists and the work that they contributed to Windows 7 personalization.

    image

     

     

    Yuko Kondo
    From Japan, now resides in London, England

     

    image

    Katharina Leuzinger
    Born to Swiss and Japanese parents in Zurich, Switzerland, Katharina Leuzinger now resides in London, England

    image 

    Osmand Nosse
    Wicklow, Ireland

    image

    Klaus Haapaniemi
    From Finland, now based in London, England

    image

    Chris Sickles of Red Nose Studios
    Indiana, United States

    image

    Punga
    Buenos Aires, Argentina

    image

    Pomme Chan
    Born and educated in Bangkok, Pomme Chan now resides in London, England.

    image

    Kustaa Saksi
    Amsterdam, Netherlands

    image

     

     

     

     

     

    Paul Hwang and Benjamin Lee of Nanosphere
    Los Angeles, California

    image

    Adhemas Batista
    From Sao Paulo Brazil, now resides in Los Angeles, California

    image

    Kai and Sunny
    London, England

    image

    Nan Na Hvass
    Born to a Danish father and Chinese mother in Swaziland, Africa, Nan Na Hvass now resides in Copenhagen, Denmark.

    We hope this post has given you some insight into the Windows 7 content. We also hope that we achieved the goals we set out for ourselves with this element of Windows 7.

    -Denise Trabona and Samuel Moreau

  • Engineering Windows 7

    Improvements to AutoPlay

    • 59 Comments

    As mentioned before on this blog (regarding our UAC changes) and on the IE blog (regarding the SmartScreen® filter for malware), we have an increased focus to enable customers to be in control and feel confident about the software that they choose to run on their computers. Folks on this blog have also commented about the concerns they have specifically in the AutoPlay area. This blog entry addresses some of the changes that we have made to increase customer confidence when using their media and devices with Windows.  It is authored by Arik Cohen, a program manager on the Core User Experience team. –Steven  [Note: There was a technical problem so this post was reposted in its entirety.]

    Certain malware, including the Conficker worm, have started making use of the capabilities of AutoRun to provide a seemingly benign task to people – which masquerades as a Trojan Horse to get malware onto the computer. The malware then infects future devices plugged into that computer with the same Trojan Horse. For further information about Conficker please visit http://www.microsoft.com/protect/computer/viruses/worms/conficker.mspx

    In the following example for a USB flash drive that has photos, malware registers as the benign task of “Open folders to view files.” If you select the first “Open folders to view files” (circled in red), you would be running malware. However, if you select the second task (circled in green), you would be safe running the Windows task.

    Infected USB AutoPlay
    Infected USB AutoPlay

    People are confused why they have two tasks that appear to do the same thing – and even a knowledgeable person who is careful not to run software from an untrusted source can easily make the mistake of selecting the first task. As a result, people lose confidence and don’t feel in control.

    A growing attack

    While presenting an AutoRun task in AutoPlay has been available since Windows XP, we have seen a marked increase in the amount of malware that is using AutoRun as a potential method of propagation. According to the Security Intelligence Report, an enterprise study by Forefront Client Security found that the category of malware that can propagate via AutoRun accounted for 17.7% of infections in the second half of 2008 – the largest single category of malware infections.

    The chart below shows the increasing amount of detection reports by Microsoft anti-virus software of the class of infections that spread via AutoRun. (Note: The actual method of infection cannot be determined.)

    Infection Detections of Malware that Spread via AutoRun

    Infection Detections of Malware that Spread via AutoRun

    Currently, disabling AutoPlay completely is the only solution for consumers and enterprises to gain confidence with the use of USB flash devices on their computer. Guidance on disabling AutoPlay is available here.

    Increasing customer confidence

    Windows 7 introduces key changes to AutoPlay that keep you from being exposed inadvertently to malware like Conficker when doing your common scenarios with devices (e.g., get to the files on your USB flash drive, download pictures from an SD card, etc.).

    In particular, Windows will no longer display the AutoRun task in the AutoPlay dialog for devices that are not removable optical media (CD/DVD.) because there is no way to identify the origin of these entries. Was it put there by the IHV, a person, or a piece of malware? Removing this AutoRun task will block the current propagation method abused by malware and help customers stay protected. People will still be able to access all of the other AutoPlay tasks that are installed on their computer.

    With these changes, if you insert a USB flash drive that has photos and has been infected by malware, you can be confident that the tasks displayed are all from software already on your computer:

    Infected USB AutoPlay after AutoPlay changes

    Infected USB AutoPlay after AutoPlay changes

    On the other hand, if you insert a CD that offers software to install, Windows will still display the AutoRun task provided by the ISV during their media creation process. For example:

    AutoPlay for a CD that offers an AutoRun Task

    AutoPlay for a CD that offers an AutoRun Task

    You will first see this updated AutoRun experience in the Windows 7 RC build, and we will be bringing this change to Vista and XP in the future.

    Ecosystem Impact

    We are working with our ecosystem partners to help mitigate situations where this AutoRun change will have an impact on them.

    CDs and DVDs (including CD emulation), where the IHV specified AutoRun task authored during manufacturing, will continue to provide the AutoRun choice allowing customers to run the specified software. IHVs of generic mass storage devices should expect that people will browse the contents of the device to launch any software. The new behavior will allow customers to continue to use AutoPlay (including all Windows and ISV installed tasks) to access their media and devices while not being presented with tasks from malware. Additionally, device classes, such as portable media players and cell phones, now support Device Stage™ on Windows 7. Device Stage offers the IHV a multifunction alternative to AutoPlay where they can present links to software and common tasks, and provides additional features as you use the device.

    As you try out the Windows 7 RC, we hope these changes will make you feel more confident and in control when using your media and devices.

    -Arik Cohen

  • Engineering Windows 7

    Engineering Windows 7 Graphics Performance

    • 46 Comments

    One of the areas of any release of Windows that receives a significant amount of testing and scrutiny is the performance of graphics—desktop graphics all the way to the most extreme CAD and game graphics.  The amazing breadth of hardware supported for Windows and the broad spectrum of usage scenarios contributes to a vibrant ecosystem with many different goals—from just the basics to the highest frame rates on multiple monitors possible.  In engineering Windows 7 we set out to improve the “real world” performance of graphics as well as continue to improve the most extreme elements of graphics. This is work we do in Windows 7 and work our partners do as they work to improve the underlying hardware/software combination through drivers (note: Windows Vista drivers continue to work as they did in Windows Vista, but we've also been working with partners on updated drivers for Windows 7 which many of you have been testing through Windows Update downloads). This post looks at this spectrum of engineering as well as the different ways performance is measured.  Ultimately we want to inform you about what we have done in engineering Windows 7, while we leave room for the many forums that will compare and contrast Windows 7 on different hardware and in different scenarios.  This post is written by Ameet Chitre, a program manager on our Desktop Graphics feature team.  --Steven

    If you have gone online to check out or purchase a new PC, you must have noticed that “faster graphics” and “great performance” are always some of the key selling points. People have come to expect faster systems which enable them to edit photos, do email, watch high-definition videos and play the latest 3D games all with greater ease, often shuffling between these tasks seamlessly. Quite a few of these users refer to the enthusiast community blogs and various review sites which run graphics benchmarks and report results evaluating how fast the graphics of new hardware or software performs. Traditionally graphics performance has been measured and analyzed through 3D games but it also impacts what we call “desktop scenarios” - such as when you are using the Windows UI, moving or maximizing windows, or scrolling within Word or IE etc. The performance requirements for these desktop scenarios are quite different from3D games. In fact, this is the reason in Windows Vista Experience Index (WinEI) we give you rating for these two scenarios separately, highlighted in the image below:

    Windows Experience Index sample. Figure 1. WEI sample with Graphics capabilities highlighted.

    Graphics performance is usually assessed through many benchmarks. These can be classified into 2 broad categories:

    • Scenario benchmarks: These report performance of particular scenarios, e.g. the frame rate when flying over a terrain in a flight simulator. Many of the popular games have in-built benchmark modes that demonstrate how fast the graphics perform in scenes that are typical for that game.
    • Synthetic benchmarks: These highlight the performance of a particular aspect of graphics such as the ability to draw a number of lines as fast as possible.

    However, there are plenty of things that we all do on our PCs that don’t have benchmarks tracking them that are still quite critical to make fast. In these cases we use the instrumentation within Windows to obtain timing information and then analyze the performance.

    This blog entry discusses various aspects of graphics performance - both gaming and desktop graphics performance. It calls out the changes we made in Windows 7 to address user feedback as well as to take advantage of modern hardware to improve graphics performance.

    Desktop Responsiveness

    Many have experienced scenarios where an application, or Windows itself, stops responding momentarily. This is type of a performance issue that can be impacted significantly by the performance of graphics in the PC. We categorize these as desktop responsiveness issues.  Improving responsiveness, both in real terms and by avoiding non-responsive moments, is one of the key ways that performance is improved in the system.  It is also hard to measure.

    Measuring desktop responsiveness is a hard problem since a number of issues which affect responsiveness aren’t easily reproducible and there is a great variety of them. They are rarely caught by either kind of benchmark as these issues are dependent on real-world combinations of factors. For Windows 7 we spent a great deal of time looking at these performance glitches using a mechanism in test versions of Windows 7 which has the ability to record key OS events and when they occurred. During real-world testing when we encounter a responsiveness problem, the tester can hit a record key and enter a small description of the issue encountered. The event history with diagnostic information called a “performance trace” is written out to a file and uploaded to a server where a team of performance analysts parse the data to figure out the cause of the responsiveness issue. This process has been successful to the extent that today most responsiveness issues can be quickly tracked down and root-caused.

    Using this methodology, we analyzed thousands of desktop responsiveness traces where the tester experienced a frozen desktop anywhere from 100msec to several seconds. The type of issues ranged from an antivirus blocking disk access for all applications while updating itself on the vendor’s website to an application doing network access from a UI thread. In a significant portion of these traces, we found that a GDI application is waiting on another GDI application which is experiencing slowdowns due to excessive paging activity. This was the single-most frequently occurring cause of all desktop responsiveness issues, which without this data we probably would not have assumed. Based on these investigations, we worked to improve the architecture in these two key areas:

    1. GDI Concurrency: Improve responsiveness when multiple applications are running. This required a re-architecture of the code around GDI (Graphics Device Interface) synchronization objects or “locks”.
    2. Reduction of overall memory footprint of Windows: Reduce the memory overhead of composition in the Desktop Window Manager (DWM), which is the component responsible for rendering the desktop. This helps reduce overall paging activity and thus is especially important for low-memory PCs, especially using shared graphics memory.

    These are described in more detail below.

    GDI Concurrency

    A number of performance traces we investigated in the context of desktop responsiveness pointed us to the design of a key synchronization mechanism in GDI. The performance challenge happens because the design of GDI in Windows Vista allows only a single application to hold a system-wide exclusive global lock.  While this seems obvious in hindsight, when this decision was originally made the performance characteristics of different parts of the system made this optimistic implementation perfectly reasonable.

    Existing model of GDI concurrency.Figure 2. Existing architecture of GDI concurrency.

    GDI applications running simultaneously vie for this global lock in order to render on the screen. The application that accesses the global lock prevents other applications from rendering till it releases the global lock. The situation often gets exacerbated when the application that is holding the lock needs to page in a large amount of memory from the disk since moving the memory from the disk to RAM takes a relatively long time. The above picture shows two GDI applications running simultaneously, contending for the global lock. If App X gets hold of the lock, it can render to the screen while App Y is unable to do so and waits for App X to finish.

    Windows 7 architecture of GDI concurrency. Figure 3. Windows 7 architecture of GDI concurrency.

    The solution to the problem was therefore to reduce the lock contention and improve concurrency by re-architecting the internal synchronization mechanism through which multiple applications can reliably render at the same time. Contention due to the global exclusive lock is avoided by implementing a number of fine-grained locks which are not exclusive but aid parallelism. The increased number of fine-grained locks adds a small overhead for scenarios where only a single application is rendering at a time.

    Special attention was paid to GDI application compatibility as changing internal synchronization mechanism in the most widely used API stack could potentially give rise to timing issues such as deadlocks and rendering corruption.

    This work also resulted in better rendering performance of concurrent GDI applications on multi-core CPUs. Multi-core Windows PCs benefit from these changes as more than one application can now be rendering at the same time.

    After the GDI concurrency work was implemented in the Windows 7 builds leading to the Beta, we saw a large reduction in the number of desktop responsiveness issues reported by our testers which were caused by one application blocking another one due to GDI. To further validate the scalability of our new implementation, we wrote tests that draw 2D GDI primitives and measured the rendering throughput by launching simultaneously multiple such applications. The throughput is measured by adding together the frame rate (FPS) of each application window. Below is a sample of these results on a quad-core CPU system.

    GDI Concurrency -- Scalability

    Figure 4. GDI Concurrency and Scalability.

    Without the Windows 7 GDI concurrency, the rendering throughput of these applications is effectively limited to the performance of a single CPU core. Since only a single application can acquire the global exclusive lock while the others are waiting, this scenario doesn’t benefit from multiple CPU cores. This demonstrates that GDI applications in Windows 7 are now much less dependent on one another. This benefit will not need any new display drivers; it will work on any Vista (WDDM 1.0) and newer display drivers.

    Desktop Graphics - Reduced Memory Footprint

    Another area which affects system responsiveness is memory usage. Simply put, increased system memory (RAM) usage leads to an increased paging activity which directly leads to reduced system responsiveness. Thus, for the best responsiveness, all applications, processes and OS components need to use as little system memory as possible.

    In Windows Vista, the amount of memory required to run multiple windows scales linearly with the number of windows opened on the system. This results in more memory pressure when there are more windows or if the monitors have higher resolution. It gets worse if you have more than one monitor. As part of investigating various means to improve system responsiveness, we saw a great opportunity in reducing the usage of system memory by DWM. In Windows Vista, every GDI application window accounts for two memory allocations which hold identical content – one in video memory and one in system memory. DWM is responsible for composition of the desktop through the graphics hardware. Hence, it requires a copy of the same allocation in video memory, which is easily accessible by the graphics hardware. The duplicate copy present in system memory is required because GDI is being rendered utilizing the CPU completely in the operating system without any assistance or “acceleration” by the graphics hardware. As the CPU performs all the tasks for rendering GDI applications, it requires an easily accessible cacheable copy of memory.

    Existing memory allocations.

     

    Figure 5. Existing memory allocations.

    Windows 7 saves one copy of the memory allocation per application window by getting rid of the system memory copy entirely. Thus, for a GDI application window visible on the desktop, the memory consumed is cut in half.

    Windows 7 memory allocations.

    Figure 6. Windows 7 memory allocations.

    We achieved the reduction in system memory by accelerating the common GDI operations through the graphics hardware - the WDDM drivers accelerate these to minimize the performance impact of the CPU read-back of video memory. This was necessary as performing these operations otherwise on the CPU would incur a heavy performance penalty. In order to decide which GDI operations to accelerate, it was important to understand the usage pattern of various GDI applications. We profiled the top 100 GDI applications to learn more about their calling patterns and frequency and nature of the GDI operations.

    Calling patterns and frequency of GDI operations for 100 GDI-based applications.

     

    Figure 7. Calling patterns and frequency of GDI operations for 100 GDI-based applications.

    Based on real-world application statistics, a tiny snapshot of which is seen above, we worked with our graphics IHV partners to provide support in their drivers to accelerate the most commonly used GDI operations. Windows 7 systems with these updated drivers, called “WDDM v1.1” will thus benefit from this memory savings work. Please note that WDDM 1.0 drivers continue to function and are fully supported on Windows 7.  You might have seen Windows Update providing these 1.1 drivers during the Beta—these drivers are themselves in Beta.

    DWM memory consumption.

    Figure 8. Desktop Window manager memory consumption comparison using WDDM 1.1 v. WDDM 1.0.

    The above data shows that the memory savings become more and more pronounced when you have multiple application windows visible on the desktop. Since you save a lot of system memory, the paging activity gets reduced – as a result, your system responsiveness improves for the same workload.

    Certain trade-offs had to be made for the desktop responsiveness improvements which benefit a wide range of systems. For example – the elimination of the duplicate system memory copies which “speed up” certain operations introduced slightly reduced performance as the CPU now has to read data back from the video memory. An analysis of real-world application statistics showed that these operations were rare. However, certain GDI micro-benchmarks which issue these operations show some performance degradation. This is something to note if you are running existing benchmarks that stress specific GDI operations repeatedly, which isn’t necessarily a reflection of real-world performance.  Our observation has been that these slow-downs do not impact the end-user functionality directly and that the memory savings directly result in Windows 7 being much responsive overall.  The improvements overall are definitely noticeable on memory constrained PCs with shared memory graphics.

    Gaming Performance

    No article on graphics performance is complete without talking about gaming, which is still the most widely analyzed and discussed aspect of graphics performance. There are a number of popular benchmarks such as 3D Mark as well as in-game benchmarks which are really a mode in which you can run your game where it renders the game scenes and animations without any user interaction. This area has thus been well tracked by the gaming industry through various industry benchmarks, which are pretty realistic and representative of actual games. The different benchmarks and tests are widely discussed and gamers all well-versed in the subtleties of these measurements and translating them into recommendations depending on their hardware, drivers, and gaming expectations.

    For Windows 7, we have worked closely with our Graphics IHV partners, helping them improve the WDDM drivers’ gaming performance with specific changes to how Windows 7 works under the hood, while maintaining the same driver model and compatibility. Our continued investments in performance tools has helped us and our IHV partners track down and analyze various gaming performance bottlenecks and fix them in subsequent driver releases. The fundamentals of the Windows Display Driver Model remain unchanged in Windows 7. Some policies around GPU scheduling and memory management were changed to enable better performance in certain scenarios.

    Because these benchmarks are very sensitive to the specific hardware, firmware, drivers, and overall system and because these are so widely measured and discussed elsewhere we are going to leave these comparisons to third parties.  Like many areas in Windows 7, our commitment is to engineer even better performance across many dimensions.  We believe it is better for you to experience these efforts directly.  In comparing Windows 7, we would encourage the comparison using Windows Vista SP1 and keep in mind the difference you might see in WDDM 1.0 v. 1.1 and that the 1.1 drivers are still under development.

    In Closing…

    As you can see, in engineering Windows 7 we have worked hard to improve the architecture for graphics for real-world performance. It benefits both ends of the hardware spectrum – by enabling low physical memory systems to run a leaner and faster Windows and at the same time enabling multi-core PCs render multiple graphics applications much more efficiently.

    -Ameet

  • Engineering Windows 7

    Ink Input and Tablet PC

    • 71 Comments

    There’s a strong community of developers who take advantage of the ink input/TabletPC functionality to develop unique solutions for specific markets (medicine, education, line of business) and create software in Windows that builds on this experience to streamline how these end-users interact with information on their PC (usually with unique form-factors such as slates or wall mounted PCs).  Earlier this week I received a great email asking “what’s new for us” from the head of development for one such ISV (medical software) and so we put together an overview of the new functionality.    Several Program Managers on the team authored this post. 

    Also, as you have noticed, the site has had some uptime troubles over the past 10 days or so and I think we’re all back to normal.  That’s ok since we’ve also been pretty busy in the Windows 7 hallway :-)   --Steven

    Tablet PC Input Panel

    Hi, my name is Jan-Kristian and I’m a Program Manager on the Core User Experience team for Windows 7. One of my focus areas is pen and touch text input, and I’d like to share some of the exciting things we have been working on.

    The Tablet PC Input Panel, what we often called the TIP for short, is the tool to insert text using handwriting into any Windows application. It also has a soft-keyboard you can use for text entry. The Input Panel has been around since the first version of Windows XP Tablet PC Edition, and we’ve made steady improvements to the user experience in each version.

    The new Writing Pad

    Our goal with the TIP is to make it as light-weight as possible so you can think about what you are writing and not how you are doing it. We received a lot of positive feedback on the improvements we did to the Input Panel in Windows Vista, but there were still areas that caused confusion or took more steps than necessary.

    Writing Pad

    Windows Vista Input Panel – The handwriting recognition results are shown as small text bubbles under the writing surface. To verify recognition you need to look down at the bubbles, if you see an error you then tap on a bubble to bring up a secondary window for correction.

    Based on analysis of our telemetry from Vista and usability tests we focused on two significant areas of improvement for Windows 7:

    • Simplify the experience – Handwriting should be an easy, natural, flowing experience. What we found though, was that using the TIP caused a “high cognitive load”, which means you have to think too much about what you are doing. Your eyes needed to dart back and forth between what you’ve written and the little bubbles down below and corrections meant entering another mode and even then often meant rewriting the whole word. Our goal was to simplify this and make it less taxing.
    • Add flexibility – We’re all accustomed to the flexibility of using a mouse and keyboard for input. Handwriting with the Windows Vista Input Panel had minimal flexibility because the ink-based model made it hard to edit a sentence once it was written – there was no way to insert more text between words, or to easily replace words. Our goal here was to bring the editing experience more in line with what you are used to with the mouse and keyboard while exploiting the power of the pen.
    Creating a new model

    To achieve these goals we needed to make fundamental changes to the writing pad. As we explored different ideas we decided on a model where ink was converted in-place to text as the user was writing. Although this sounds like a straightforward UI model, there were a lot of open questions on what the right behavior should be: when do we convert, how big should the text be, what font should we use… The only way to make sure we created a natural and efficient handwriting experience was to get real user feedback. We utilized the RITE (Rapid Iterative Testing and Evaluation) method. RITE testing is a cycle-based usability method that was developed at Microsoft as part of usability testing of the Age of Empires II game. For each cycle you try to make small improvement to the user experience and then you re-test to see how well it worked. We went through roughly 20 cycles before we had a design that we felt was ready to be documented.

    One of the most important things we adjusted during RITE testing was the timing for the automatic ink to text conversion. Converting too early or too late would break the user experience; to get this right we had to do a lot of behind the scenes work. Our final solution is a combination of a distance trigger (automatically adapting to the user’s average word spacing), recognizer-result-based trigger, and a time-based trigger. Another factor was the text size, in the end we use dynamic sizing to closely match the size of the handwriting.

    The new text-based UI in the writing surface allows you to get to the text they wanted faster. Having a single representation of the text makes the experience less complex and reduces the height of the Input Panel. Using text instead of ink makes the writing surface much more flexible as we can move the text around as much as we want – inserting a word between two words is now as simple as just starting to write in the space and we will auto-grow the space as much as needed.

    With the ink to text conversion working we needed a correspondingly natural way of editing recognized text. Gestures seemed to be the perfect solution for this - we were creating a pen-based UI, so we should use the pen. We limited ourselves to a small number of gestures: delete, split (add space), and join. We collected samples of how people would perform these three actions on paper. Based on our collected data we then created our gestures. To make the gestures discoverable, we added the “gesture panel”, which is an interactive “cheat sheet” in the title bar of the Input Panel.

    Let’s take a look at how this all comes together in the new Windows 7 writing surface [Ed. Note, used YouTube with Windows Live Photo Gallery on Windows 7]:

    Windows 7 - Handwriting overview

    Writing Pad: The new writing pad in action, animation is used to provide meaningful transitions so that the user can easily see the result of their actions.

    Smart Corrections

    Our telemetry showed us that corrections were one of the more painful parts of using the TIP in Vista, to correct a word you often had to rewrite all of the characters. In Windows 7, we leveraged work from Microsoft Research to design the Smart Correction feature to make word corrections much faster. Now you just start correcting a word left-to-right and Windows performs a new recognition every time you enter a character. This constrained recognition will almost always give you the desired result within a few character corrections.

    Windows 7 - Handwriting Smart Correction

    Smart Corrections: “worked” is auto-corrected to “wonderful” with just a single character change. All you have to do is start correcting the word from the left and it will keep updating until you get the word you want.

    Entering URLs

    One extra writing pad feature worth mentioning: our instrumentation data showed that the most used applications with the Input Panel are web browsers, and when you are browsing one of the main scenarios is to enter URLs.

    Windows 7 Handwriting - URL correction

    Entering URLs: The flexibility of the new writing pad makes entering URLs easy by pre-populating parts of the URL

    Notice how the different URL segments are separated and all have alternates that make sense. The alternates are based on what you use most frequently, so if you choose “.net” a lot then that will become the top alternate and set by default in the URL template. The “Insert” button also changed to “Go to” to let the user insert the URL and navigate to it with a single click.

    Touch Keyboard

    The Input Panel also has a soft-keyboard available which is great for the Pen or Touch. Some of the updates we made might seem like only visual changes, but they were very deliberate and have a big impact on the usability of the touch keyboard. For example, touch screen PCs are often used in mobile situations, we had to be very careful with the color and contrast of the key labels to make sure they are visible on a dimmed screen or in less than optimal light conditions.

    Touch Keyboard

    The Windows 7 Touch Keyboard

    One of the challenges with using a touch based keyboard is the lack of tactile feedback. Coupled with this is the fact that user’s fingers cover keys as they are being tapped. How does the user know that they hit the right key (or even hit a key at all) when they are covering the key with their finger? If a user has to switch focus between the text field and the touch keyboard for every key press they will quickly tire of typing using touch. We wanted to give the user a simple little nudge; “we heard you”, and “yes, you just hit this key”. Our solution was to let the released key have a short glow fade-out effect. This glow feedback gives the user a subtle confirmation that they hit the key they wanted (or not).

    The keyboard now supports multitouch so you can press “ctrl+c” or “shift+a” etc. We also enabled key rollover, meaning you can press another key before you finger has lifted off the previous one – this enables a much more natural typing experience. Don’t worry, if you prefer the sticky modifier-key model, where you press “Ctrl” then press “c”, it is still supported.

    Predictive Text and Handwriting Personalization

    Hi, my name is Jen and I’m a Program Manager on the Tablet PC Handwriting Recognition team. In our previous post you heard from my co-worker Yvonne about new handwriting recognizers. I’m going to talk about some of the new features that leverage or augment our recognizers including Predictive Text and Personalization as well as our new East Asian Recognizers.

    Text Prediction

    One of our goals on the Tablet PC team is to make it as efficient as possible to enter text when using your keyboard is inconvenient or impractical. To achieve this we’ve made investments in the TIP, we’ve improved overall handwriting recognition accuracy, and we’re leveraging some of these same technologies to deliver Text Prediction on the soft keyboard. Text Prediction offers possible completions for the word being entered, and may offer suggestions for next words or phrases.

    Text prediction

    Text Prediction – Here I am trying to input the word “Microsoft” using the US English soft keyboard. After entering the first two letters “Mi”, the word “Microsoft” is proposed as the first option. I can then select this option and have the word “Microsoft” inserted into a document.

    In Windows 7, we support Text Prediction for English, French, Italian, German, and Spanish using the soft keyboard as well as for Traditional Chinese and Simplified Chinese using handwriting in character by character mode. This section will focus on the Latin based languages; examples for Chinese can be found in the following section.

    As we developed Text Prediction, our primary goal was to speed up user input. To do so, we had to make sure predictions were relevant. Our recognizers use a lexicon to improve recognition accuracy. The system lexicon ships with the recognizer and is a fancy name for a word list of the most commonly used words in a given language. Using this lexicon, the out-of-the-box predictions are good, but by including additional user-specific words (your words), we can improve accuracy significantly. This is where Text Harvesting comes in.

    In Windows Vista, we shipped Text Harvesting (or Automatic Learning) for US English and UK English to improve handwriting recognition. In Windows 7, this feature will be available for all languages. It allows us to automatically extend the system lexicon based on the words you type when writing email. Text Harvesting is done on a per user basis, so your data is specific to you. From the results of Text Harvesting, we build a new lexicon containing your specific vocabulary and also increase the probability of words already you commonly use, this is use for both handwriting recognition and text prediction. The results are impressive, after augmenting the lexicon with your words and usage patterns, prediction can seem almost magical in its ability to predict which words you are going to enter next!

    Windows 7 also includes support for Custom Dictionaries, these are specialized word lists that can be added to the system. Companies can develop domain specific dictionaries, such as for medicine, chemistry etc. and add them to the system – predicting acetaminophen is a lot faster than typing it!

    Improvements in East Asian Handwriting Recognition

    Significant improvements were made to handwriting recognition on the four East Asian languages we support: Traditional Chinese, Simplified Chinese, Korean and Japanese. For many people, handwriting is an efficient input method for these languages due to the large character set.

    There are two input modes for East Asian handwriting: character by character mode (or box mode) and freestyle mode (or line mode). In box mode, you input a single character at a time into a fixed width box. In freestyle mode, you write the characters cursively on a line and do not have to concentrate on spacing. Which mode you chose depends on your preference; box mode is slightly more constrained but has text prediction and is more accurate, whereas line mode is closer to natural handwriting.

    Traditional Chinese recognition

    Traditional Chinese recognition - recognized input.

    Traditional Chinese in Line Mode – The top pane contains the user’s writing and the bottom pane contains the recognized text.

    In addition to core accuracy across all these languages improvements, we also use personalization to improve the user experience. One method of personalization is to adapt to how you write using the Shape Collector. The Shape Collector is a Wizard that allows you to train handwriting recognition on your individual handwriting style. For the four East Asian Languages, you can use the Shape Collector in a “troubleshooting” mode to improve recognition of a specific character or word, or to add a character or word that is unsupported.

    We also learn as you write and correct mistakes. If you write a character and it is initially misrecognized, you can view the alternates list and select the character you intended. We will learn based on this action, and be more likely to provide that as the first choice the next time you write the character.

    In Windows 7, Simplified Chinese and Traditional Chinese also support Text Prediction in box mode. For these languages, Text Prediction is especially valuable as writing individual characters can be time consuming. The user writes in character by character mode and is provided with options to complete their word or phrase without having to write the whole thing. In the case below, the user wants to input 中华人民共和国 and only has to input the first two characters (中华) to get the desired text as a prediction. The gray words represent what has been entered and the black shows the predictions.

    Traditional Chinese in box mode.

    Notice in this example that Text Prediction is working on both characters together (中华) as well as just the second character (华). As with the other languages, Text Prediction also works with user-specific vocabulary. If a user inputs the same words multiple times, the recognizer will learn this behavior.

    We have made significant improvements to Traditional Chinese, Simplified Chinese, Japanese, and Korean handwriting recognition since Windows Vista. These were based on improving our overall customer experience by improving accuracy and throughput. Our goal is to give customers a more natural way to input in these languages and a viable alternative to keyboard use.

    Math Handwriting Recognition

    Have you ever written a math paper in Word or performed calculations in Mathematica, and spent hours creating equations using a multitude of buttons or a complex linear format, thinking: “Oh, what I wouldn’t give for an easy-to-use input method?” Well, your wishes have just come true, in addition to improving handwriting in Windows 7, we have also invested in recognizing ink drawn math equations.

    Hi, my name is Marko and I am the Program Manager for math recognition in Windows. Let me show you the Math Input Panel that provides you with the most natural and efficient way of math input: handwriting recognition. We have taken a completely new approach to this problem and raised math handwriting recognition to a whole new level in terms of functionality, performance and area coverage.

    The Math Input Panel (or MIP) is designed to be used with a tablet pen on a Tablet PC, but you can use it with any input device such as a touchscreen, external digitizer or even a mouse. MIP outputs the recognition result via the clipboard in MathML format, a standardized mathematical markup language. Any equation you write and recognize in MIP reaches your destination application in a completely editable form – you can insert and edit the output as you would edit any text.

    We spent a lot of time researching and identifying as many areas of math as possible and endless different math notations. The final result is a great coverage of high school and college level math, and of even more advanced areas. Math Input panel

    Math Input Panel – Have you heard of the formula recognized in the example above? You haven’t J, well, it’s the Schwarz formula used in complex analysis!

    Using MIP is really simple and straightforward. You write the well-formed math expression (this means that clip_image016 will not get recognized, whereas clip_image018 will) just as you do with pencil and paper and the recognizer takes over. The recognized math is shown in the preview area. As no recognizer is perfect, the great power of MIP lies in its ability to provide a fantastic correction experience (let’s be honest, sometimes even a human is not sure what has been written – you should see my handwriting!).

    In case your handwritten math is misrecognized, you can select any part of it (symbols or whole sub-structures) and correct it either by selecting an alternate from a drop-down list or by rewriting part of the expression. Usually fixing one part of the equation automatically fixes the rest, in just one step.

    Math Input correction

    Math Input Panel Correction

    All you have to do now is tap Insert and you have just painlessly created an equation in your word-processing or computational program.

    There are many other cool features like History, moving ink around, and dragging and dropping ink into MIP from other inking applications such as OneNote, all of which you can explore on your own. For software developers, the MIP can be embedded into your applications – check out the documentation on MSDN.

  • Engineering Windows 7

    Delivering a quality upgrade experience

    • 294 Comments

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

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

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

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

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

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

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

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

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

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

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

    clip_image002

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

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

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

    THANK YOU!

    --Windows 7 Team

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

  • Engineering Windows 7

    Touching Windows 7

    • 68 Comments

    We’ve come a long way in engineering Windows 7 since we first provided an engineering preview of Windows 7 and the work we are doing to support the touch interface paradigm back at the D: All Things Digital conference.  We chose to kick-off the discussion about engineering Windows 7 with touch scenarios because we know this is a long-lead effort that requires work across the full ecosystem to fully realize the benefit.  For Windows 7, touch support is engineered by building on our advances in input technology we began with the TabletPC work on Windows XP.  Touch in Windows 7 requires improvements in hardware, driver software, core Windows user experience, and of course application support.  By having this support in an open platform, consumers and developers will benefit from a wide variety of choices in hardware, software, and different PC form factors.  Quite a few folks have been a little skeptical of touch, often commenting about having fingerprints on their monitor or something along those lines.  We think touch will become broadly available as the hardware evolves and while it might be the primary input for some form factors (such as a wall mounted display in a hospital, kiosk, or point of sale) it will also prove to richly augment many scenarios such as reading on a convertible laptop or a “kitchen PC”.  One of my favorite experiences recently was watching folks at a computer retailer experience one of the currently available all-in-one touch desktops and then moving to another all-in-one and continuing to interact with the screen—except the PC was not interacting back.  The notion that you can touch a screen seems to be becoming second nature rather quickly.  This post is our first dedicated blog on the subject. This is a joint effort by several people from the touch team, mostly Reed Townsend, Dave Matthews, and Ian LeGrow. -Steven

    Windows Touch is designed to enhance how you interact with a PC. For those of us that have been living and breathing touch for the last two years we’re excited to be able to deliver the capability to people using Windows 7. In this blog we’re going to talk about what we’ve done to make Windows touchable. We approached this from a number of different directions: key improvements to the core Windows UI, optimizing for touch in key experiences, working with hardware partners to provide robust and reliable touch PCs, and providing a multitouch platform for applications.

    Making Windows Touchable

    With Windows 7 we have enriched the Windows experience with touch, making touch a first-class way to interact with your PC alongside the mouse and keyboard. We focused on common activities and refined them thoughtfully with touch in mind. You will have the freedom of direct interaction, like being able to reach out and slowly scroll a web page then flick quickly to move through it. With new touch optimized applications from creative software developers you will be able to immerse yourself as you explore you photos, browse the globe, or go after bad guys in your favorite games.

    While providing this touchable experience, we made sure you are getting the full Windows 7 experience and not a sub-set just for touch. We’ve been asked if we are creating a new Touch UI, or “Touch Shell” for Windows – something like Media Center that completely replaces the UI of Windows with a version that is optimized for touch. As you can see from the beta, we are focused on bringing touch through the Windows experience and delivering optimized touch interface where appropriate.  A touch shell for launching only touch-specific applications would not meet customers’ needs – there would be too much switching between “touch” mode and Windows applications. Instead, we focused our efforts on augmenting the overall experience so that Windows works great with touch.

    We took a variety of approaches – some broad, and some very targeted to support this goal:

    • Touch gestures: Windows 7 has a simple set of touch gestures that work in many existing applications. These include the basics of tap and drag, as well as scroll, right-click, back, forward, zoom, and rotate. More details on how gestures work is described later.
    • Improved high DPI support: Windows 7 has improved high dpi support (see High DPI blog post). The broad benefit to touch is that UI elements are rendered closer to their intended size – usually larger – which makes small buttons, links, and other targets easier to access with touch.
    • Improved window management: The updated taskbar and windows arranging features go a long way towards making Windows easier to use with touch. There have been several subtle but critical touch optimizations:
      • The taskbar buttons and thumbnails are ideally sized for pressing with touch, and specific behaviors are tuned for touch input. For example, the Jump Lists can be accessed with a simple drag up from the taskbar, and when opened with touch, the shortcuts in the Jump Lists are drawn with extra vertical spacing to make them easier to select.
      • Aero Peek has been tuned to work with touch – the show desktop button is twice as wide (the only visual sign you are on a Windows Touch PC) and instead of hovering (which you can’t do with touch), a press-and-hold on the button activates Aero Peek.
      • Sizing and positioning windows is easy with Aero Snap – just drag a window to a screen edge. Furthermore, this was tuned with special touch thresholds so that you don’t have to drag to the absolute edge of the screen – a better balance for touch usage.
    • Refinements to key experiences: The top browsing and media activities were refined to provide an optimized touch experience. IE8 includes support for the core touch gestures (scrolling, back, forward, zoom) as well as an optimized address bar that opens by dragging down, and extra spacing in favorites and history lists when opened with touch for easy selection. In Windows Media Player, the transport controls (play, pause, etc) have larger clickable areas even though they still look the same size – so that they are easier to touch.
    • Touch keyboard: The on-screen keyboard has been optimized for touch with glow key feedback that’s visible when your finger is covering the letter and multitouch support for natural typing behavior and key combinations. It’s designed for quick usage, like entering a URL.

    Overall, the Windows Touch features are designed to work together to deliver a great end-to-end touch experience. For example, the goal with IE8 was to deliver a seamless touch browsing experience, this includes the panning, zooming, URL entry, and several interface enhancements. For this reason, all the new touch features require the presence of a multi-touch digitizer – more on that further down.

    Gestures

    The Windows Touch gestures are the basic actions you use to interact with Windows or an application using touch. As we noted above, because the gestures are built into the core of Windows, they are designed to work with all applications, even ones that were never designed with touch in mind.

    Our mantra with gestures has been “Predictable + Reliable = Habits”. To be predictable the action should relate to the result – if you drag content down, the content should move down. To be reliable, the gesture should do roughly the same action everywhere, and the gesture needs to be responsive and robust to reasonable variations. If these conditions are met then people are far more likely to develop habits and use gestures without consciously thinking about it.

    We’ve intentionally focused on this small set of system-wide gestures in Win7. By keeping the set small we reduce misrecognition errors – making them more reliable. We reduce latencies since we need less data to indentify gestures. It’s also easier for all of us to remember a small set! The core gestures are:

    • Tap and Double-tap – Touch and release to click. This is the most basic touch action. Can also double-tap to open files and folders. Tolerances are tuned to be larger than with a mouse. This works everywhere.
    • Drag – Touch and slide your finger on screen. Like a dragging with a mouse, this moves icons around the desktop, moves windows, selects text (by dragging left or right), etc. This works everywhere.
    • Scroll – Drag up or down on the content (not the scrollbar!) of scrollable window to scroll. This may sound basic, but it is the most used (and most useful – it’s a lot easier than targeting the scrollbar!) gesture in the beta according to our telemetry. You’ll notice details that make this a more natural interaction: the inertia if you toss the page and the little bounce when the end of the page is reached. Scrolling is one of the most common activities on the web and in email, and the ability to drag and toss the page is a perfect match for the strengths of touch (simple quick drags on screen). Scrolling is available with one or more fingers. This works in most applications that use standard scrollbars.
    • Zoom – Pinch two fingers together or apart to zoom in or out on a document. This comes in handy when looking at photos or reading documents on a small laptop. This works in applications that support mouse wheel zooming.
    • Two-Finger Tap – tapping with two fingers simultaneously zooms in about the center of the gesture or restores to the default zoom – great for zooming in on hyperlinks. Applications need to add code to support this.
    • Rotate – Touch two spots on a digital photo and twist to rotate it just like a real photo. Applications need to add code to support this.
    • Flicks – Flick left or right to navigate back and forward in a browser and other apps. This works in most applications that support back and forward.
    • Press-and-hold – Hold your finger on screen for a moment and release after the animation to get a right-click. This works everywhere.
    • Or, press-and-tap with a second finger – to get right-click, just like you would click the right button on a mouse or trackpad. This works everywhere.

    For touch gestures, seeing them in action is important so here is a brief video showing the gestures in action:

    Windows 7 Touch Demonstration

     

    In order to make the gestures reliable, we tuned the gesture detection engine with sample gesture input provided by real people using touch in pre-release builds; these tuned gestures are what you will see in the RC build. We have a rigorous process for tuning. Similar to our handwriting recognition data collection, we have tools to record the raw touch data from volunteers while they perform a set of scripted tasks. We collected thousands of samples from hundreds of people. These data were then mined looking for problems and optimization opportunities. The beauty of the system is that we can replay the test data after making any changes to the gesture engine, verifying improvements and guarding against regression in other areas.

    This has led to several important optimizations. For example, we found that zooms and rotates were sometimes confused. Detecting zoom gestures only in applications that don’t use rotation has resulted in a 15% improvement in zoom detection.

    Gesture success data.

    Further analysis showed that many short gestures were going unrecognized. The gesture recognition heuristics needed to see 100ms or 5mm worth of data before making a decision about what gesture the user was performing. The concern that originally led to these limits was that making a decision about which gesture was being performed too early would lead to misrecognition. In fact, when we looked at the collected user data, we found we could remove those limits entirely – the gesture recognition heuristics performed very well in ambiguous situations. After applying the change and replaying the collected gesture sample data, we found zoom and rotate detection improved by about 6% each, and short scrolling improved by almost 20%!

    Supporting Gestures

    Gestures are built into the system in such a way that many applications that have no awareness of touch respond appropriately, we have done this by creating default handlers that simulate the mouse or mouse wheel. Generally this gives a very good experience, but there are applications where some gestures don’t work smoothly or at all. In these cases the application needs to respond to the gesture message directly.

    In Windows, several experiences have been gesture enabled. We’ve spent a considerable amount of effort on IE8 – ensuring scrolling and zooming are smooth and that back and forward are at your fingertips. Media Center, which is a completely custom interface ideally suited to touch, added smooth touch scrolling in galleries and the home screen. The XPS Viewer has gesture support that will could become a model for many document viewing apps. Scrolling and zoom work as you would expect. When zooming out beyond a single page, pages start to tile so you can view many at a time. When zoomed out in that fashion, double tapping on any page jumps back to the default view of that page. A two-finger tap restores the view to 100% magnification. These predictable behaviors become habit forming quickly.

    Working with the Hardware Ecosystem

    A major benefit of the Windows ecosystem is diversity – PCs come in all shapes and sizes. To help ensure that there is a great Windows Touch experience across the many different types of PCs we have defined a set of measurements and tests for Windows Touch that are part of the Windows Logo. We’ve been working with touch hardware partners since the beginning of Windows 7 to define the requirements and ensure they are ready for launch.

    Our approach has been to provide an abstraction of the underlying hardware technology. We’ve specified a requirements for the quantitative aspects of the device, such as accuracy, sample rate, and resolution, based on the requirements to successfully enable touch features. For example, we have determined the necessary accuracy values for a device so people can successfully target common UI elements like close boxes, or what sample rate and resolution are required to ensure quality gesture recognition.

    The requirements form the basis for the Windows Touch logo program. For consumers, the logo tells you that the PC and all of its components are optimized for Windows. Component level logo, which is what we grant to Touch digitizers helps the OEMs choose a device that will deliver a great touch experience.

    Based on the quantitative requirements, we built an interactive test suite that includes 43 separate tests, all validating the core requirements under different conditions. There are single point accuracy tests at various locations on the screen, including the corners which are often harder for accuracy but critical to Windows. There are also several dynamic tests where accuracy is measured while drawing lines on the screen – see the screenshot below of Test 7. In this test, two lines are simultaneously drawn using touch along the black line from the start to the end. The touch tracings must remain within 2.5 mm of the black line between the start and end points. The first image below shows a passing test where the entire tracing is green (apologies for the fuzziness – these are foot long tracings from a large screen that have been scaled down).

    Figure 1: A passing line accuracy test from the Windows 7 Touch logo test tool

     

      Figure 1: A passing line accuracy test from the Windows 7 Touch logo test tool

    Not all devices pass the tests. Below is a screenshot of a device that is failing. This one has some noise – notice the deviation from the line in red. These errors need to be resolved before it would receive the logo. Errors like this can result in misrecognized gestures.

    Figure 2: A failing line accuracy test from the Windows 7 Touch logo test tool Figure 2: A failing line accuracy test from the Windows 7 Touch logo test tool

    To ensure repeatability of the tests, we’ve built a set of plastic jigs with tracing cut-outs, see photo below. This particular jig is used for 5 of the tests and measures accuracy while tracing an arc.

    Plastic jig with tracing cutouts to ensure repeatability of tests.Figure 3. Plastic jigs with tracing cut-outs for testing.

    The testing tool is available to our partners now, we’re working closely with several of them to help tune the performance of their devices to meet the requirements and deliver a great touch experience. We have set-up an in-house testing facility that will be testing every device submitted for Logo.

    With the Release Candidate, OEMs and IHVs will be able to finalize the logo process for systems designed for Windows 7. Today we already have several hardware partners that have provided us with devices and drivers for testing.

    Windows Touch for Software Developers

    We also want to talk a little about the touch platform for software developers.  Windows 7 provides a rich touch platform for applications. We’ve already mentioned gestures, there’s also a lower level platform that gives developers complete control over the touch experience. We think about it in a Good-Better-Best software stack.

    Good

    The “good” bucket is what touch-unaware applications get for free from Windows 7. Windows provides default behaviors for many gestures, and will trigger those behaviors in your application in response to user input. For example, if someone tries touch scrolling over a window that is touch-unaware, we can detect the presence of various types of scrollbars and will scroll them. Similarly, when the user zooms, we inject messages that provide an approximation of the zoom gesture in many apps. As a developer you can ensure that the default gestures work just by using standard scrollbars and responding to ctrl-mouse wheel messages.

    Better

    The “better” bucket is focused on adding direct gesture support and other small behavior and UI changes to make apps more touch-friendly. For instance, there is a new Win32 window message, WM_GESTURE (preliminary MSDN docs), that informs the application a gesture was performed over its window. Each message contains information about the gesture, such as how far the user is scrolling or zooming and where the center of the gesture is.

    Applications that respond to gestures directly have full control over how they behave. For example, the default touch scrolling is designed to work in text centric windows that scroll primarily vertically (like web pages or documents), dragging horizontally does selection rather than scrolling. In most applications this works well, but if an app has primarily horizontal scrolling then the defaults would have to be overridden. Also, for some applications the default scroll can appear chunky. This is fine with a mouse wheel, but it feels unnatural with touch. Apps may also want to tune scrolling to end on boundaries, such as cells in a spreadsheet, or photos in a list. IE8 has a custom behavior where it opens a link in a new tab if you drag over it rather than click it.

    In addition to gestures, there are subtle optimizations applications can make for touch if they check to see if touch is in use. Many of the subtle touch behavior optimizations in Windows were enabled in this manner. Larger Jump List item spacing for touch, larger hot spots for triggering window arranging, and the press and hold behavior on the desktop Aero Peek button with touch are all features written with the mouse in mind, but when activated via touch use slightly different parameters.

    Best

    Applications or features that fall into the “best” bucket are designed from the ground up to be great touch experiences. Apps in this bucket would build on top of WM_TOUCH – the window message that provides raw touch data to the application. Developers can use this to go beyond the core system gestures and build custom gesture support for their applications. They can also provide visualizations of the touch input (e.g. a raster editing application), build custom controls, and other things we haven’t thought of yet!

    We also provide a COM version of the Manipulations and Inertia APIs from Surface. The Manipulations API simplifies interactions where an arbitrary number of fingers are on an object into simple 2D affine transforms and also allows for multiple interactions to be occurring simultaneously. For instance, if you were writing a photo editing application, you could grab two photos at the same time using however many fingers you wanted and rotate, resize, and translate the photos within the app. Inertia provides a very basic physics model for applications and, in the example above, would allow you to “toss” the photos and have them decelerate and come to a stop naturally.

    Showcasing Touch

    We’ve previously demonstrated, Microsoft Surface Globe, an interactive globe done in partnership with the Surface effort. Spinning the globe works as you would expect from a real-world globe, but with a touchable globe you can grab and stretch the view to zoom in, rotate, and move the view around. Interacting with the globe and exploring the world is the majority of the UI, and it is exceedingly easy to use with touch. Other features like search and adding markers to the map have also been designed with touch in mind.

    Here’s another video to get an idea of what we’re talking about:

    Windows 7 Touch Demonstration of Surface Globe

     

    We’re eagerly looking forward to seeing new touch-optimized user interfaces and interactions. If you’re thinking about writing touch applications or adding touch support to your existing app, you should start with the MSDN documentation and samples.

    What Next?

    We’ve noted several touch updates in the RC. If you have the Windows 7 Beta you can experiment with touch using a PC that supports multiple touch points. Please note that the multitouch PCs available today were developed while the Windows 7 requirements were also defined, so while we believe they can support Windows 7’s requirements, only the maker of the PC can provide the logoed drivers for Windows 7 and support the PC on Windows 7. Keeping that caveat in mind, today there are a few multitouch PCs on the market:

    • HP TouchSmart All-in-One PCs (IQ500 series & IQ800 series)
    • HP TouchSmart tx2 Tablet PC
    • Dell Latitude XT or XT2 Tablet PC

    To enable multitouch capabilities on these PCs running the Windows 7 Beta you will need to make sure you have the latest multitouch beta drivers. Remember these are pre-release drivers and are not supported by Microsoft, Dell or HP. And again, they still need to pass through the Windows Logo process we described above before they are final.

    • For HP TouchSmart All-in-One PCs: The pre-release driver is available from Windows Update. After you have installed the Window 7 Beta, open Windows Update from the Start menu. You might have to click the “Check for Updates” link on your left so it will find the driver, it is Optional right now so you’ll have to select it before it will install. Alternatively you can download it from the NextWindow website.
    • For the Dell Latitude XT, XT2 and HP TouchSmart tx2 Tablet PCs: the drivers are available on N-Trig’s website. N-Trig is the company that makes the digitizer in these PCs (you should read the release notes, there are some limitations, like no pen support – that will be fixed by RC – you should be aware of and how to switch between Windows Vista and Windows 7).

    We often get asked about single-touch PCs. Will they work with Windows 7? There are many types of hardware available for touch and many screens and PCs can provide single touch (usually based on resistive touch technology).  A single-touch PC will have the same functionality on Windows 7 as it does on Vista, but this functionality will not be extended to the Windows 7 capabilities. As we noted earlier, Windows Touch in Windows 7 is comprised of a collection of touch enhancements, several of which require multitouch, that work together to deliver a great end-to-end touch experience.

    As form factors change and the demands of our user interfaces change, input methods change and grow as well. We’re excited about the unique benefits touch offers the user, and the new places and new ways it enables PCs to be used.  We expect PCs of all form factors and price points to provide touch support and so it makes sense that these PCs will be able to take advantage of the full range of Windows 7 capabilities.

    Windows 7 is designed to provide efficient ways to use multitouch for the most common and important scenarios, while being a natural and intuitive complement to the mouse and keyboard people use today.

    Keep in Touch!

    - Windows Touch Team

  • Engineering Windows 7

    Federating Windows Search with Enterprise Data Sources

    • 60 Comments

    The Windows Explorer has evolved by enabling you to find all sorts of content by searching for it. Many of you have used the search features in Windows Vista (based on our instrumented data) from the start menu or from the search box in Explorer. It has been a long time since most of us could remember where everything is by carefully managing our folder hierarchy and finding things based on file name alone.  We often rely on domain specific search (in music players, mail clients, photo clients) but with Windows Vista and Windows 7 we make it possible to search within a namespace and across namespaces.  This post is about a new feature based on Search that allows searching across PCs and even servers in an Enterprise setting.  Alwin and Scott, program managers, and Brandon, a developer, on the “Find and Organize” feature team authored this post. --Steven

    Finding your stuff

    Whether you’re searching or browsing, Windows Explorer is really about finding your stuff, and once you’ve found it, doing something with it (such as copying, opening, deleting, etc). For data that lives on your PC or home network, Windows 7 has invested in HomeGroup and Libraries (subjects for a future posting from our team) to provide an easier and richer experience than ever before. However, we didn’t stop there. Over the last few years, we’ve seen enterprise customers’ important content migrate towards (or aggregated in) centralized content stores, such as SharePoint. These products typically provide great features for team collaboration, document versioning and workflow management, archiving, retention policy enforcement, and other centrally-managed functionality that IT managers appreciate.

    Where Enterprise Data Lives

    Important enterprise data is found on local machines, in a variety of centralized content stores and also beyond the firewall

    Unfortunately, this has placed an extra burden on customers to learn each new content store’s user interface, often asking them to give up familiar desktop features like drag-and-drop. Given their collaborative focus, these sites grow organically and it can become hard to remember where a particular document was stored and then wade through long lists of them every time you want to get back to it. Enterprise customers have asked us for a solution that simplifies finding important content in these various data stores but without leaving their normal Windows work flows.

    As we looked at this trend and the lack of integration with content management and content indexing web services, we used these guiding principles in developing a solution:

    • Natural for people to use. Customers want a more consistent experience for finding and working with data in these disparate content stores, and would like us to bridge the local and remote content experiences by helping them “roll over” from one to the other.
    • Easy for IT admins to deploy. IT admins don’t like to deploy code, and want low-maintenance solutions that are easy to manage. Meanwhile customers want to connect up these sources without going through long and tedious installation processes or having to get help every time they want to set up a new search location.
    • Easy for developers to adopt. Developers want to enable this functionality in their offerings quickly and easily. There are a lot of data sources which need to be supported because IT folks don’t want to be locked in to a specific server technology.

    Choosing to build Federated Search

    Federated Search wasn’t the only way to address these challenges. The brute force approach would have been to take our existing Windows Search indexing technology and just use it on these content stores—that index the remote content on a local PC. This isn’t a very realistic solution since it’s inefficient to have all content indexed over the network by each person’s machine, especially when the content is changing at a rapid pace and represents a large corpus. Corporate retention policies may also prevent keeping even a local index of certain sensitive data.

    Fortunately, there’s a better option – Federated Search. Federated Search enables you to search a remote web service from Windows explorer and get results back that you can act on like any normal file. The largest barrier to doing Federated Search has already been taken care of too. That is, most of these content stores are already indexed on the server, or at least on some server. There are several great offerings that will accomplish this, such as Microsoft Search Server. Not only do these servers index this content, but many of them already expose search results via a standard web protocol. This is largely thanks to the prevalence of OpenSearch and RSS enabled clients (including Internet Explorer and Microsoft Search Server, among many others).

    For Windows 7, we’ve added support for Federated Search using OpenSearch v1.1 and worked to make the experience a seamless one. We found this solution strikes a good balance by leveraging the strengths of content services and the strengths of local file interactions within Windows.

    Natural to use

    Using Windows Explorer, people are familiar with several important user interface and interaction elements. They know how to use the navigation pane to change what they’re looking at. They know how to scroll around, how to select an item (or several), and they know how to double-click to open them. Most people know how to right-click for context-sensitive options related to their selection, or how to find those options presented in the command bar. They know they can drag and drop items to move them around. They know how to change view modes. We hope that they know how to search their current location using the search box, and in Windows 7 we think we’ve made it much easier to discover and use the Preview Pane to make sure they’ve got the right result.

    Searching Sharepoint from Windows Explorer in Windows 7

    Searching a SharePoint site using the new Federated Search support in Windows Explorer

    Much of the usefulness of building Federated Search into Explorer is our ability to take advantage of this knowledge and familiarity. This may seem obvious once you see it in action, but behind the scenes there’s quite a lot going on to make all of this happen. For example, some applications such as Microsoft Word already know how to work with web URLs. So opening a Word document from a web server is fairly straightforward. But the majority of applications you’ll encounter really only understand how to open files on the local machine or via standard network file sharing protocols. This includes everything from the built-in software like Notepad and Paint, to third-party software like Photoshop or iTunes.

    To handle this case, we implemented a “just in time” download solution, which will download the file to the internet cache before opening an application or taking actions (like using the SendTo menu) which require local files. This lets us offer searches that are very “lightweight” from a server load perspective, where we display metadata and icons or thumbnails without ever requesting the actual file. Then if you take an action like previewing or opening an item, we will do some behind-the-scenes work to make a local copy of the file only if necessary.

    That enables us to work with the existing application ecosystem without asking anything of developers. However, applications can also take steps to offer even better functionality in many cases. For example, Windows Photo Viewer has added support for non-file items. So if you open a picture result in the built-in photo viewer, it’s the photo viewer that downloads the item, not Explorer. This may not seem like a big deal, but it lets the photo viewer enable the forward and back buttons to jump to the next or previous result – and it will download that image on-demand. Starting at the PDC we began reaching out to third-party ISVs to encourage them to implement similar enhancements for Federated Search scenarios, and we will continue to offer guidance on how to best integrate with all of the newest Explorer features.

    Finally, we support all the standard clipboard and drag-and-drop operations. So if you drag a Word document from a Federated Search query onto your desktop, it will be copied there. You’ll even see the familiar Windows Explorer copy dialog, with progress indication, cancel ability, conflict resolution, and so on.

    But wait, there’s more! Windows Explorer is a great tool that many customers know and love. But some people use it without even knowing it. Countless Windows applications make use of what we call the Common File Dialog. This is a special Explorer window that lets you find and choose items to be opened or inserted into your current application, without ever leaving it. If you’ve ever clicked File and then Open or Save in an application menu, you’ve probably seen some version of this dialog. PowerPoint, for example, uses the common file dialog to insert pictures. That means from inside PowerPoint you can click Insert Picture, select the Federated Search link for your image repository, search for the picture you want, and then insert it directly into PowerPoint. This works for any existing application that supports the Common File Dialog, and there are a whole lot of them!

    Inserting a picture into PowerPoint’s using Federated Search

    Inserting a picture into PowerPoint’s using Federated Search

    Our Federated Search solution is all about simple lightweight access with a common, familiar user interface. This has a lot of benefits as we described above, but there are also cases where a server’s web interface will offer its own benefits. This might involve advanced query building, browsing, or server work-flow tasks, for example. So Windows 7 builds a bridge to these content repositories. After doing a search against a supported location, you will see a “Search on Website” button in the command bar which allows you to seamlessly send the query up to the service’s web interface in the default web browser. You’ll also see the “Open File Location” menu item when you right-click on a search result. Selecting that option will launch the web browser to the specific location in the document repository where the file is stored.

    This seamless integration of Federated Search within Windows allows customers to greatly simplify their workflow for getting at remote files while still being able to easily take advantages of the advanced functionality of content repositories.

    Simple to deploy

    Our next challenge was to make it easy for customers to get these new connections onto their machines. It wouldn’t be practical to ship Windows with a connection to every solution in the world, so we shifted to a way that would make it very easy for any web service to deploy a connection to their specific service.

    The model we came up with is similar to the way you add favorites from the web today. A web service can place a link to an .osdx file somewhere on their web page (see Channel 9’s search page for an example). The .osdx file is a simple XML file that uses the OpenSearch description document format to describe how to connect to the web service, and gives the web service some control of how the data is presented in Windows Explorer. When a person clicks on the link, Windows performs an ultra-lightweight install process that adds a search connector to that web service and places a link to that it in the Windows Explorer favorites.

    If you are an administrator in an enterprise environment, you will likely want to provide some pre-installed search connectors for your users to search the company intranet or a popular internal SharePoint site for example. You can do this by deploying the search connector (.searchconnector-ms) files to your users’ machines via typical deployment techniques such as imaging, group policy preferences or startup scripts. The beauty is that it’s just a simple XML configuration file and there’s no code that needs to get installed on their machines. It’s also possible to pin one of these as a link from the Start menu through group policy. In the group policy editor look for the policy in this area: User Configuration> Administrative Templates > Windows Components > Windows Explorer. The policy name is “Pin Libraries or Search connectors to Search again links and start menu”.

    Launching a Federated Search of an enterprise Intranet from the Start Menu

    Launching a Federated Search of an enterprise Intranet from the Start Menu

    Easy to adopt

    Of course this technology depends on having services that support it. Although there are only a few services that provide a .osdx for you today, there are many existing services that already support the basic OpenSearch requirements.

    We’re already seeing positive initial reactions from enthusiasts and ISVs alike echoing that it is indeed easy to enable your service to work with our Federated Search platform. If you’re a developer and want to enable an existing web based service to support Windows 7 Federated Search, you’ll need to provide a web service that accepts an http GET request with the search terms embedded somewhere in the URL and be able to return the results as an RSS or Atom feed. These requirements are typically very easy to meet for most applications that already provide search services via a web browser.

    Your web service results should include the basic RSS tags like <link>, <title>, <description>, <pubDate> to get started but there’s much more that you can include in the RSS output and customization you can do within the .osdx file to enhance the experience for the end user.

    For more information, we’ve published the Windows 7 Federated Search implementer’s guide with detailed information on how to enable your data source to work with Windows Federated Search. There’s also a recorded PDC session that demonstrates how to build a Windows Federated Search compatible web service for an existing SQL database.

    - Brandon Paddock, Scott Dart & Alwin Vyhmeister, Find and Organize

  • Engineering Windows 7

    Designing Aero Snap

    • 76 Comments

    Here’s a behind the scenes look at the design of the Aero Snap feature in Windows 7.  We thought it would be fun to take a look at the overall design process of the feature and the tools and techniques used.  This feature poses a unique design challenge in that you just use the feature without any user-interface specifically to invoke it.  As with all features this is a collaboration across all of our engineering disciplines.  For this post, Stephan Hoefnagels, a Senior UX designer, presents the design perspective.  --Steven (P.S., keep an eye out on the Microsoft MIX conference this week!)

    In Managing Windows windows and Follow-up: Managing Windows windows we talked about, and you shared, some interesting window management scenarios that we might address in Windows 7. We also touched on some data around typical configurations, as well as goals that guide our thinking in this area.

    In this post we’d like to have a closer look at the Aero Snap feature that many of you have already been able to experience in our PDC builds, and of course the Beta. We’ll briefly describe the feature itself, but mostly we’d like to invite you to take a behind-the-scenes peek at our design process so far, and share our iterations, challenges and considerations.

    Goals and scenarios

    As we explained more in depth in our previous post, our top goal for the Aero Snap feature is to provide you with an effortless way to position your windows the way you want them. We want to reduce the number of clicks and precise movements needed to perform common activities. In a general sense, we want you to be able to manage your windows with confidence and create a feeling of power and control. This is something we touched on in our post on the Windows 7 taskbar as well, and really a theme that weaves through much of our new desktop experience.

    Before we look at how we address our goals in the design, a quick note. In the scenarios below you’ll notice sequences of interactions that are fully written out. Sequences like: select the window, click the caption button, and then resize the window. Looking at interactions at this level of detail makes for somewhat awkward reading. These individual steps are so small, and so frequent, that for most of us they normally barely register. Why not simply gloss over some of those details? Well, we spell out sequences of events this way to force us to be consciously aware of the amount of “overhead” that is sometimes involved to get to the task at hand. It forces us to realize what we normally might not. Also, besides providing insight in the problems, it provides us with the right level of detail to consider our solutions.

    Now, let’s look at the design!

    Side-by-side windows

    As many of you mentioned, doing a drag drop operation from one window to another is sometimes a pain. Windows tend to overlap and to get them positioned right can require a lot of fine mouse movement. Oftentimes the steps are as follows: select a window, resize it appropriately, and position it on the screen so that enough of it shows for it to be a meaningful drag or drop target. Then repeat the same actions with the other window. Similarly, comparing content in two windows requires a lot of mouse clicks, resize actions, careful arrangement, window switches, and a fair amount of mouse mileage.

    With Aero Snap you can grab a window and move your mouse to the edge of the screen and the window will resize to fill half the screen. Repeat with the other window. Now with two easy motions you have a setup that makes both of these scenarios much easier to accomplish!

    Put windows side-by-side with Aero Snap by moving the cursor to the edge of the screen (left to right, top to bottom)

    Put windows side-by-side with Aero Snap by moving the cursor to the edge of the screen (left to right, top to bottom)

    Vertical maximized windows

    We know our users love the maximized window state. Many love it so much that they maximize all of their windows and never even run in any other state! However, with screens increasing in resolution and widescreen layout becoming more prevalent, the maximized window state can lose some of its appeal in certain cases. E-mail is an example. Reading long lines of text across the screen is not ideal. Your eye simply cannot track a line all the way across. Web browsing is another example. Content will sometimes not fill the entire width of the screen, leaving a lot of unused white space on the side.

    Now, with Aero Snap you can you can maximize a window in the vertical direction only. When you resize a window to the top of the screen, it will also resize all the way to the bottom. Great for reading long blog posts!

    Vertically maximize a window with Aero Snap by resizing the window to the edge of the screen

    Vertically maximize a window with Aero Snap by resizing the window to the edge of the screen

    Moving maximized windows from screen to screen

    We realize there are a few multi-mon users out there, especially amongst the readers of this blog ;-). Ever wanted an easier way to move a maximized window to another screen? A way that’s quicker than clicking the restore caption button, moving the mouse to the title bar, dragging the window over, and finally clicking the maximized caption button again? With Aero Snap you can simply drag a maximized window down, move it over and snap it to the top, all in one gesture. Finally!

    Arranging windows on laptops

    Arranging windows on a desktop PC can sometimes involve excessive fiddling, fine mouse movements and lots of mouse mileage, as touched on above. On laptops this situation is further exacerbated by the lack of a mouse, making some of these movements even more cumbersome. For these scenarios, and our power users, we’ve introduced some convenient key combinations. Hold down the Windows key and one of your arrow keys to give it a try. You may want to try holding down Shift as well, especially if you’re in a multi-mon setup.

    Design process

    OK - So those are the scenarios, and the way we chose to address them. Seems straightforward enough, right? Especially for those of you that have been using Aero Snap in out Beta build. It all behaves as you’d expect. But how did we get here? Well, in this next bit we’d like to something that we don’t do that often and really give you a peek into our design process so far and some of the snags we ran into along the way. Keep in mind that this is a brief overview and by no means exhaustive. While we allude to usability testing for instance, this post is by no means meant to give insight into the scope of those efforts. There will certainly be opportunities to talk about some of those topics in the future.

    Let’s have a look!

    Sketching

    We’re back in early 2007, and after we established window management as a potential area of interest, and identified several appealing scenarios (again, see our previous post for more detail on that stage of the process), we started with brainstorms to generate ideas. “How can we make window arranging more efficient?” “More direct?” “More fun?” are some of the questions we asked ourselves. This was a multidisciplinary process, with disciplines like design, user research, program management and development involved. All in all there were around a handful of us, certainly less than a dozen, thinking about this space at the time.

    We imposed a significant constraint on ourselves: we wanted to achieve our goals without introducing any extra widgets in our UI. Imagine an extra caption button on the window title bar for instance: this may not seem too bad for one window, but when we’re talking about 10 windows or more, we’ve all of a sudden introduced a significant amount of clutter on your screen. And that’s something that we simply didn’t feel good about. After all, as we shared in our UX Principles talk at the PDC, we believe in “Solving Distractions, not Discoverability”.

    We captured our, many, ideas in very quick sketches that we shared via an internal website. Transferred from the whiteboards in our offices and hallways, these took less than 5 minutes to sketch each. The sketches below are some actual examples in which you can start some of the Aero Snap ideas forming.

    Early ideas are captured in quick and disposable sketches

    Early ideas are captured in quick and disposable sketches

    Interactive prototyping in early code

    With so many ideas on paper we were eager to try out the best ones. Now was the time to prototype. Note that we are still very early in the process. We wanted our prototypes to be interactive, and we wanted to be able to live with them in our day-to-day work. So we chose to implement the ideas using early code that we could run on our work machines. For example, the image below shows a “smart resizer” prototype running on Windows Vista. Of course these prototypes are not “done” features that we could actually ship: they merely get the basic ideas working, and they definitely have more than a few “quirks” (bugs ;-)). What’s important however, is that they allow us to experience just enough of the interactions ourselves, as well as get feedback in usability studies.

    Early “smart resizer” prototype running on Windows Vista, note the taskbar button created by the prototype (and the date in the calendar to get a sense of where we are in the process)

    Early “smart resizer” prototype running on Windows Vista, note the taskbar button created by the prototype (and the date in the calendar to get a sense of where we are in the process)

    We use this firsthand experience and early usability feedback to iterate on the ideas as we hone in on the final design. We approach this part of the process in a very open minded way and allow ourselves to be surprised. Sometimes ideas that don’t look like much on paper prove to be startlingly powerful. On the other hand, we found out that others look much better on paper than they were in practice! Since we’re not invested in any one idea or implementation yet, we freely refine, and drop ideas.

    Finally, the prototypes ease us into thinking about design details. And we might stumble on some insights too (of course we tell ourselves the real feat is to recognize the insight and hold on to it). Here’s an example from an e-mail at the time from one of the team members about a new version of the “smart resizer” prototype:

    I noticed something changed. In the original version if I resized it to the max it “supersized” the window. Then if I resized the window smaller, it jumped back to the normal restored state. It was as if the supersize state was different than restored state. With this version when I supersize the window and then resize it again later, it doesn’t jump back to the previous restored size. There was something kind of nice about the supersized state being different than the restored state. We should think about it more and consider making that a part of the design.

    After many a prototype we settled on the concept of side-by-side windows and vertical maximized windows. We’re getting clearer on what we want to build.

    Detailed design: state transitions

    OK - We’ve whittled down our ideas to a good, but not fully specced, set of interactions and behaviors. Time to start filling in the blanks by asking detailed questions. “What does it mean to have a side-by-side window in a world where there used to be only minimized, restored and maximized windows?” “How exactly would you get to and from this new window state?” The e-mail snippet above already pointed to some of these questions.

    Currently the common window states are (left to right) minimized, restored, and maximized, how would side-by-side and vertical maximized windows fit in?

    Currently the common window states are (left to right) minimized, restored, and maximized, how would side-by-side and vertical maximized windows fit in?

    Let’s look at the state problem in detail. Below is an example of two proposals made during this time that show how you can move from one window state to another, for all the different states. Which model is better?

    Two proposals detailing the various ways we can transition between states

    Two proposals detailing the various ways we can transition between states

    To answer that question we considered more specific questions like “What states do we want to link directly and how do we move between them?” “Is it compelling to go from a vertical maximized state directly to a maximized state?” “Should the vertical maximized and side-by-side states behave similar, as they look similar?” Our answers of course guided us to the model that you are now familiar with, which is model B.

    But that’s not the end of it. More details need to be worked through, and more questions come up. “What if I want to move a vertical maximized window sideways?” “Resize its width?” “Then pull it down?”

    Soon you’ll find yourself in elaborate sequences of events, many possible actions, and even more possible outcomes. Which would be the most expected when actually using the entire system?

    To help guide our decision making process we established some guiding statements. Assumptions that we hold to be true. Examples are: “The intuitive way to undo an effect triggered by a mouse movement is to make the opposite mouse movement.” And: “It should always be effortless to go back to the previous “restored” state so as to avoid excessive work to get the window back to a reasonable size.” Or: “If the user specifies a width for a window in a given state, that size should be preserved across state changes when it makes sense.”

    Using these statements we were able to answer questions like the ones above in a predictable way and as a result craft a predictable experience. And while the underlying state transitions and rules are fairly complex when added all together, the resulting behavior is, we hope, intuitively understood. That’s definitely something we’re aiming for.

    Conflicting rules

    Here’s an example of a sequence problem for the really attentive reader. When working through our many new state transitions, sometimes the rules that determine what should happen, conflict. Consider the following scenario. Two rules in our new window model are:

    1. Dragging a window to the top of the screen maximizes it
    2. The intuitive way to undo/cancel an effect triggered by a mouse movement is to make the opposite mouse movement

    OK – Let’s try the following scenario in your Windows 7 build. Start with a restored window. Vertically maximize it by resizing it to the top of the screen. Release the mouse. Drag (don’t resize) down the window and drag it to the top again, all in one motion. Release the mouse. What happened?

    Your window should be maximized. Which means in this case we chose to follow rule 1. We could have also followed rule 2, in which case your window would be vertically maximized. We figured rule 1 would more accurately reflect the user’s mental model for this scenario.

    This is just one example of the decisions we had to make for each transition to and from a window state.

    Throughout this process we made sure to preserve the subtleties in the current model. One small example that some of you may be familiar with that we did tweak is the scenario of dragging a window title bar off screen. In previous Windows releases we would snap the window back halfway in an attempt to provide you with just enough space to still move the window around, while optimizing vertical space as much as possible. We chose to be a little more deliberate and straightforward here by snapping back so that the entire title bar is visible. This way you can start to rely on the fact that all of your windows are always very easy to grab, also with touch, and move around. If we really felt half of a title bar is enough, why don’t we always half it, right? For our vertical maximized window states we of course chose to keep the entire title bar visible as well, leading to a solid story all around.

    Storyboards and other visualizations

    State diagrams are of course only one way to look at the world. We used various ways to communicate different aspects of the feature, picking our medium based on familiarity, availability and intent. We didn’t even shy away from the occasional ASCII art as you can see below! We’ll simply use whatever tool gets the point across. Most of all, interaction storyboards were a very valuable technique to help us understand the user flows, and even though this is only a small sample, you can see we did quite a few of those.

    Feature details are communicated throughout using appropriate means

    Feature details are communicated throughout using appropriate means

    Accidental triggers

    Besides figuring out the right state transitions, one or our biggest discussions was around when a state transition should exactly occur, or in other words: when the feature is triggered. We talked a lot about “accidental triggers”, i.e. running into the feature without deliberately setting out to do so.

    Aero Snap is triggered by touching the edge of the screen with the mouse

     

    Aero Snap is triggered by touching the edge of the screen with the mouse

    From the very beginning we always made sure that our feature did not get in the way of current scenarios such as tucking a window off-screen to the side. After all, we don’t want to have a detrimental effect on your current, expected, way of managing your windows. That’s why you have to literally touch the edge of the screen with your mouse, not the window edge, to trigger the transitions.

    However, at this time, the feature as you know it now was different in one very important, fundamental way. In our early builds, Aero Snap followed an “instant commit” model. When you moved your mouse to the top of the screen, your window would literally be maximized while you’re still dragging. That is, before you even release the mouse. Moving back in one motion would literally restore the window. We liked this approach as the “preview” was very accurate, i.e. the preview was the window, and there is a certain directness in not having a commit model.

    Because our UI is invisible by design, we expected some accidental triggering. In fact in some sense we were relying on accidental triggers to help with the discoverability of the feature. However, after living with the builds for a while we got a little worried because accidental triggering seemed higher than we expected. From our telemetry data we saw people running into the feature, and then cancelling it nearly twice as often as committing. In our usability studies we observed confusion as to what exactly triggered the behavior. Was it the window touching the edge that did this? A gesture? Or something else?

    We’re now in early 2008. What should we do? Cut the entire feature? We actually did consider this as an option. Again, we really respect our current window management behaviors, and the last thing we wanted to do is degrade the experience. More constructively, we took on the challenge to come up with a design tweak that would address these issues. We explored several solutions. Some conservatively centered on smoothing out the resize transitions, so an accidental trigger would at least be smooth. A conservative approach for sure, but probably not satisfying enough as a real solution. Others focused on trying to detect user intent more accurately, based on the angle of motion into the screen edge, or the speed of the motion. This proved much too complex to be predictable. Maybe we could trigger the transition only when double-bumping the edge? We were worried that this would degrade the experience of fluidity and flow of the current model.

    In the end we settled on the implementation you’re familiar with. We don’t trigger until you release the mouse, making it easy to back out of the effect before anything happens to your window. In addition we provide you with a smooth preview animation, and a cursor effect to help you understand what just happened. This way you can be more deliberate in the future, and use the feature to your full advantage.

    Did we solve the issues? Feel free to let us know :-)

    Look and feel

    It’s interesting to think back and realize that up to this point we had essentially designed a feature without any visible UI whatsoever. Now all of a sudden we have window previews, and a cursor effect. What should those look like, and how should they behave?

    Well, luckily we had some things to go on. At this point we had already established a clear picture of our taskbar look and feel (we call it “personality” and will talk about it more in a later post). We had settled on using glass sheets for Aero Peek. We saw an opportunity to use the same visual representation for our preview windows. But how should the glass sheets appear? After experimentation, we settled on a scale animation that originates from the cursor. This gives a subtle hint as to where this preview window came from. We also made sure to animate our transitions. Try this in your build for instance: move a window to the top, and then to the side, in one motion without releasing the mouse. Notice the smooth morph of the preview? Why did we spend time on this? We believe “Small Things Matter, Good and Bad” of course.

    Light effects are used to indicate the snap trigger, and glass sheets for snap previews

    Light effects are used to indicate the snap trigger, and glass sheets for snap previews

    Finally, we tied into some of our ideas around “light” for the trigger indication. We tuned this to be noticeable, but not too loud and made sure to synch with other light effects in the system such as our touch feedback.

    We hope this post has given you some insight in the Aero Snap feature, including our design process. We would love to hear your thoughts!

    Stephan Hoefnagels

  • Engineering Windows 7

    A few more changes from Beta to RC…

    • 237 Comments

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

    Desktop Experience

    1. Improved taskbar thumbnail overflow

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

    Fig 1.

    List View of running windows appears on hover and supports close

    List View of running windows appears on hover and supports close

    2. Control Panel Jump List

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

    Fig 2.

    The Control Panel Jump List now surfaces recently used items

    The Control Panel Jump List now surfaces recently used items

    2. PowerShell Jump List

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

    3. Remote Desktop Jump List

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

    4. Applying taskbar settings

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

    Touch

    5. Multi-touch zoom

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

    Windows Explorer and Libraries

    6. Invert Selection

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

    7. Going up?

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

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

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

    Fig 3.

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

    beta parent folder

    Fig 4.

    In RC, parent folders always remain within single click access

    RC parent folder

    8. Finding music by artist

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

    9. New folder is always available

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

    10. Right-click in Windows Explorer

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

    11. Content view for search results

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

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

    12. Intelligent re-indexing after application installation

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

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

    Performance

    13. Trimming sound schemes to help performance

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

    Device Stage

    14. Baseline Device Stage experience

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

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

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

    Fig 5.

    Baseline Device Stage experience for a mobile phone

    Baseline device stage experience

    15. Devices and Printers enhancement

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

    Fig 6.

    Device Stage experience for a PC

    Device Stage experience for a PC

    Devices and Printers

    16. Unified experience for removing devices

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

    17. Hardware properties

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

    18. Improved eject experience

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

    19. USB device reliability on resume

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

    20. FireWire camera support

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

    Device Installation

    21. Add Legacy Hardware functionality restored

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

    22. Increased responsiveness of Add Printer Wizard

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

    System

    23. Partition size reduction

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

    24. Reserved System Partition naming

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

    25. Dual Boot partition drive letter assignment

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

    26. Pagefile reduction

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

    Network

    27. Improved driver support

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

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

  • Engineering Windows 7

    Application Compatibility Testing -- International

    • 60 Comments

    This post continues the discussion of Compatibility testing from our test team.  --Steven

    In the previous blog post "Application Compatibility Testing for Windows 7" we talked about the importance of Application Compatibility and work we are doing to engineer this in Windows 7. In this post we will examine the challenge that emerges as we consider the world wide audience that Windows serves.

    This blog post will cover the following areas:

    • Overall International App Compatibility Strategy
    • Approach to International App Compatibility
    • Application Acquisition
    • Testing Applications
    • Measuring our Success
    • What it means to “Rescue An Application”

    For Windows 7 we have made significant investment in application compatibility, ensuring applications that worked on Vista, continue to work on Windows 7 and we’ve also rescued some applications that were broken in Vista to work on Windows 7 (more on that later).  As we’ve talked about, there are some applications that are OS version specific by design (utilities, firewalls, security, etc.) and those are not included in this discussion.

    Approach

    One of the biggest challenges in International Application Compatibility is what applications we test, the scale of testing, and what it means for us to say that an application “works”.  For Windows 7 we are testing over 1200 applications across 25 specific markets.   We have improved our coverage over Vista by adding over 300 more international applications.

    We look at applications in 3 buckets.

    1. Global ISV (GISV) Applications – Localized software sold by major ISVs in several international markets as well as the United States.
    2. Microsoft (MS) Localized Applications – Microsoft software that has been localized for use in other markets other than the United States.
    3. 3rd Party Local Applications – Software where the user interface language is not-English and the application is sold in non-English speaking markets (for example, IchiTaro – Japanese Word Processor, Парус 8 – Russian ERP system,)

    Categories 1 & 2 are pretty straightforward.  There are a known set of key applications and scenarios used around the world and we must ensure these applications function in Windows 7.  Category #3 is where there is some complexity.

    The applications list we build for 3rd Party Local Applications is built using a number of methods. First, we build on the list of applications we have used in previous versions Windows (XP/Vista, etc). If it worked on Vista, it must work on Windows 7. 

    Next we work with our teams in markets around the world to rank top applications in particular markets.  It is amazing to see the diversity in application use around the world.   The application testing list is based on a combination of market data where it is available, individual knowledge of markets, culture, revenue, usage and even sometimes just “word on the street”.  The cultural knowledge in these markets is probably most critical to our success. For example, casual gaming in Korea is hugely popular and we need to ensure our Windows 7 testing accounts for this. 

    Our goal in selecting applications is to test as many applications as we can that will expose the most issues across different scenarios and markets. 

    These scenarios include:

    • Productivity
    • Memories (photo editing and sharing apps, etc.)
    • Graphics
    • Productivity
    • Music
    • Fundamentals (security, data backup, etc.)
    • TV/Movies

    Application Acquisition

    Once we build the list of applications we need to test the next process is acquiring them.  We acquire applications in a variety of ways but many times we have to buy an application from a retail store just as any end user would.  Other methods we use to acquire applications include downloading full featured trial versions, purchasing software, and working with ISVs to acquire their applications to ensure compatibility.

    Testing Applications

    Testing applications means more than just installing them and making sure they launch.  Every application gets a unique test plan written for it to cover as much functionality as we can.  We write test cases to cover primary and secondary application functions – for our word processing example this would include opening a file, typing a letter, adjusting formatting, save, and print, emailing a copy to someone, etc.  These applications go through 6 or more test passes during the product cycle.

    Now, we can’t test every piece of every application and we do run into some interesting challenges when we focus on a worldwide audience.  Many applications depend on location specific information (meaning if you aren’t testing the application in that location – you aren’t likely to have the information needed).  Examples include  Brazilian citizen’s CPF ID, or Brazilian personal number of identification which would be required to test something like tax preparation software. We run into similar problems with SMS applications requiring active local mobile phone accounts.

    What it means to Rescue an Application

    Along with the core tenet of ensuring that any application that worked on Windows Vista also work on Windows 7 we have a stretch goal to “raise the bar” and make applications work on Windows 7 that never worked on Windows Vista. For Windows 7, we have some good news early in the development cycle.   So far we have made over 30 applications that were “broken” on Vista work on Windows 7.  This means that Windows 7 will have higher application compatibility than Windows Vista.  We are continuing to push this number up.  Below is a table of the # of applications by language that we have made to work on Windows 7 but didn’t’ work on Vista.

    Language Number of
    Apps Fixed
    Example Applications
    Arabic 1 Khalifa Cartoon Characters Creator
    Chinese (Simplified) 1 Arcsoft WebCam Companion
    Chinese (Traditional) 3

    Asure Purchase/Sale/Stock Master 2008

    Cyberlink DVD Suite v6

    Asure Accounting Master 2008

    Czech 1 J.K.R. BYZNYS
    Danish 1 Bogskabet 3.2
    German 2

    QuickTime 7.1.6

    Haufe Personal Office Professional - Haufe Formular-Manager

    Hebrew 3

    Compedia Timmy in English World

    Compedia Moomins: The Search for the Ruby

    Compedia The Puzzling Time Quest

    Hungarian 1 Infocentrum Road Register
    Italian 5

    Finson Costo del Lavoro Italian v2

    Finson Falco 6

    Finson Progetto Condominio

    Finson Contintasca 7

    Finson ContinBanca

    Japanese 5

    PostPet v3

    Kenchako Adventure 9.0

    WZ Editor 5.0

    QuickTime 7.1.6

    Overland LOKI: with Japanese Manual

    Norwegian 1 Visma Avendo Fakturering
    Polish 2

    WF-Fakturka dla Windows

    Nahlik eTeacher 5

    Portugese 1 Mr. Escola Win Port
    Spanish 3

    Mexico Federal Taxes Simplified SAT: Individual Taxes

    Monografias Spanglish

    IKEA Home Kitchen Planner

    Turkish 1 MYTR Filter 2.6

    Along with ensuring these applications work on Windows 7 we have taken an extra step for our existing Vista customers.  Of the applications outlined in the above table, 27 of the fixes we made have been back ported to Windows Vista for possible inclusion in future updates.   We really wanted to raise the bar for application compatibility and go beyond just looking at Vista as the baseline.

    Takeaway

    There is a lot of information here and hopefully gives you some insight into what it means for us to make the application experience (application compatibility)  on Windows 7 as high as possible for users around the world.  We started out with a goal of making sure if an application worked on Windows Vista it should work on Windows 7.  We have taken that further by bringing applications that never worked on Vista to work on Windows 7 and even future updates to Vista. 

  • Engineering Windows 7

    Beta to RC Changes – Turning Windows Features On or Off

    • 133 Comments

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

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

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

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

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

    Windows Features control panel

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

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

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

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

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

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

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

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

    --Jack

  • Engineering Windows 7

    Application Compatibility Testing -- Overview

    • 50 Comments

    Delivering a new release of Windows includes a major effort to insure that applications continue to function as well on the new release as they have on the previous release. At the PDC we talked about some of the new areas of Windows Vista that reduced this level of compatibility, such as changes we made around the OS security model. With Windows 7 we renewed our engineering efforts to maintain compatibility. As with device testing, compatibility testing is an effort that spans the entire engineering organization, though we also have a group that is dedicated to this effort. This post was authored by a set of folks and coordinated by Grant George, the corporate vice president for testing in the Windows Experience team. --Steven

    We have taken a very proactive approach to Application Compatibility and our process starts from the moment we first plan our product schedule and design and check in code for Windows and runs through all of our engineering processes and disciplines leading up to our final release (and beyond).

    Application Compatibility Goals for Windows 7

    Our main Application Compatibility goal for Windows 7 is to make sure that most all applications which work on Windows Vista will continue to work seamlessly on Windows 7. We do have to be careful about making this claim to be universal because there is a class of applications that are always updated in tandem with a new Windows release. These applications are primarily system utilities, diagnostics, and security software—the common thread is that they make assumptions about the underlying implementation of Windows internals and thus require updates. We carefully coordinate with a large set of ISVs who provide these applications. This was talked about earlier this month as we announced our Ecosystem Readiness Program, which we will discuss more below.

    At the start of our product cycle we review our new features and changed designs to ensure that every element of Windows 7 has Application Compatibility in mind. Our engineering process includes automated quality checks to assure public APIs don’t change, and our test engineers have the right tools, engineering time and information that is used to find application issues as early as possible in our development cycle. Telemetry information is collected to assess and prioritize the breadth of applications our users depend on, paired with market data and install base information, across a wide variety of software categories to make sure they work as expected in our new OS version.

    Below we expand on how we deliver on this goal.

    Engineering Application Compatibility

    Rich telemetry from external usage and the broad software marketplace helps us to provide a list of the most popular and critical applications, updated frequently throughout our development cycle. Our engineers then acquire these applications and build automated tests that verify each one works as expected on Windows 7.

    Changes that could impact application compatibility are followed up closely, for example Legacy Code Removal which involves removing code that existed in the previous release of the product is strictly guarded and tightly managed and should not happen without proper documentation and engagement with the impacted parties. For example if we need to deprecate an API call, the documentation for this API will be updated and we will wait until the impact of the removal is minimal as indicated by telemetry data unless it is required sooner to fix a security issue.

    Throughout the development process we are running tests in the background creating an ongoing validation of new code relative to application compatibility. As code is getting ready to be checked into the main build, if a compatibility failure is detected in an automated regression test the checkin is halted. At that point the code is scanned for known compatibility issues and if an issue is detected the developer is asked to fix the problem. Of course we also develop new tests throughout the course of developing Windows 7 in order to broaden our coverage of third party software.

    Engineering & Testing Strategy

    We have several teams dedicated to application compatibility as part of the Windows development effort. These teams provides guidance on how to build in application compatibility, provides data on application dependencies, and information on what applications may be impacted for any particular change we make in the Windows platform. These teams also reviews new feature designs, as well as other planned changes, to ensure that the engineering team has fully taken application compatibility into account so that we achieve the tenet of "keeping applications working on Windows 7".

    In addition to working with the internal Windows engineering teams, we also reach out to 3rd party developers writing Windows applications to ensure these partners have all the information they need to make their solutions fully compatible with Windows Vista and Windows 7. Furthermore if we do uncover any issues that may need to be resolved by the 3rd party developers, we collect all the information, resources and guidance and engage in a conversation with those external developers to help them understand and fix these issues.

    We recently announced the Windows 7 Ecosystem Readiness Program. This program provides partners with access to Windows 7 builds and tools they need to test solutions for Windows 7, Windows Vista, Windows Server 2008 and Windows Server 2008 R2. The Ecosystem Readiness Program also facilitates testing multiple components of the ecosystem together to improve the overall user experience. Rather than just focusing on getting a specific OEM product, software application, or hardware device certified, we will be bringing multiple components together to verify a rich user experience that delivers quality, reliability, and performance as well as innovation through new feature adoption.

    As mentioned earlier we use telemetry data and market share information to choose the applications we directly test on as part of our compatibility efforts, below you can find the a sample of the Consumer Scenarios we focus our testing on:

    • Communications
    • Gaming
    • Fundamentals like Setup, Security and Performance
    • Memories
    • Music
    • Productivity
    • TV/Movies
    • Data Backup/Security
    • Mobility
    • Financial Management

    To view a full list of Application Categories covered please take a look at the Appendix section at the end of this post. While we would love to provide the detailed list of products, several of the sources of this information are based on proprietary research from third parties.

    Another very important set of technologies we test on are the middle tier technologies like Java, the .Net Framework, etc. to make sure the applications that use these technologies continue working as expected

    In addition to 3rd party stand alone applications we test a subset of OEM pre-installed software and their inbox applications for compatibility. The software tested come from the engagements we have with our OEM partners and their submitted installation images. These images are tested on clean installations of Windows 7 and upgrades from Windows Vista on OPEM standard hardware. This level of coverage allows us to best replicate the initial experience with Windows 7 for many of our customers. Because many of these applications are closely aligned with the OS, hardware and drivers, it is not unusual for an OEM to provide updates to this software with a new OS release.

    In addition to the above mentioned testing approaches, Microsoft IT maintains a software portfolio of approximately 1,500 applications. These applications must be tested prior to software deployments inside Microsoft.

    Microsoft IT developed an application-tracking method that simplified the process of selecting applications for sample-based testing. By identifying groups of applications that have similar data processing, controls, underlying technology, and methods, Microsoft IT is able to test approximately 4 to 6 percent of the total applications and gain a reasonable assurance of compatibility for all.

    For more information you can read the LOB Application Compatibility Technical White Paper.

    Validation Strategy

    Part of our testing process includes the creation of scenarios that we validate on 3rd party applications. We approach this by verifying the intended functionality of the application while focusing some of our attention to changes in the OS, new functionality and risky integration areas. Manual and automated test passes are scheduled to cover the identified scenarios and to verify the user experience. We cover the applications on different sets of hardware and make sure that that we cover a lot of different configurations, x86, x64, Intel, AMD, touch and multi -touch machines, etc.

    We use specific categories when measuring the compatibility of the applications we test on:

    • Excellent - No compatibility problems
    • Poor - Minor functionality is not working
    • Failure (regression) - It used to work in Windows Vista now it is not working properly
    • Failures (non-regression) - The application does not work on Windows 7 but it did not work on Windows Vista either
    • Accepted Regression - We know of changes in the OS that may affect the applications and we have/are working with ISVs on mitigations for these issues. A simple example is version number. An application that is hard coded to only work on specific versions and it doesn’t know what our new operating system version is would fail.

    We will cover these categories in more detail in subsequent blog posts about how we manage application compatibility.

    As part of our testing we do find issues that may need to be resolved by the 3rd party developers at the companies that develop and sell these applications. We collect all of the relevant technical information, resources and guidance and engage in a conversation with those external partners to help them fix the issues. Of course we also engage them in our technical beta programs so they can test Windows 7 compatibility with their products at the same time we do.

    Final Word

    Application compatibility is very important to the Windows team. We are constantly working to improve your experience with applications as you move from one release of Windows to the next. We encourage you to try our Windows 7 beta release to experience the improvements in the application compatibility space and we want to hear your feedback.

    It is worth mentioning the work we have done from an end-user perspective to assist in application compatibility. Many failures of application compatibility happen at install time and to assist with this, in Windows 7 we have improved the detection of failed installations and provided a step by step wizard which will help to get an application’s “compatibility mode” correctly set. We also provide real-time problem reports and solutions that can help you locate an updated version or patch. Many of you might have experienced this when trying to run Skype after an upgrade or install the current version, and in both cases you were automatically referred to the Beta download site.

    Appendix

    Microsoft Covered Consumer Scenarios & Application Categories

    Table of Microsoft Covered Consumer Scenarios and Application Categories

    Our list includes the top 50% best selling applications in the past 24 months, some of this data is collected and aggregated from several well-known third party research information providers.

  • Engineering Windows 7

    Some Changes Since Beta for the RC

    • 304 Comments

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

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

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

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

    Desktop Experience

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

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

    Fig 1.

    Aero Peek triggered from Windows Flip (ALT+TAB)

    Aero Peek triggered from Windows Flip (ALT+TAB)

    2. Windows Logo + <#> keyboard shortcut

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

    3. Needy State

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

    4. Taskbar “Open With”

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

    5. Taskbar scaling

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

    Table 1.

    Maximum taskbar button capacity before scrolling

    Resolution

    Large Icons

    Small Icons

    % Increase from Beta (large/small icons)

    800x600

    10

    15

    25% / 36%

    1024x768

    15

    22

    25% / 38%

    1280x1024

    20

    29

    25% / 32%

    1600x1200

    26

    39

    24% / 39%

    6. Anchoring taskbar thumbnails

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

    Fig 2.

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

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

    7. Newly installed programs

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

    8. Jump List length

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

    9. Increased pinning flexibility with Jump List

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

    10. Desktop icon and gadget view options

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

    Touch

    11. Aero Peek for touch

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

    12. Multi-touch touch keyboard

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

    13. Multi-touch right-click

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

    14. Drag/Drop and selection

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

    Networking

    15. Internet access feedback

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

    Control Panel

    16. User Account Control

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

    17. Locking a machine without a screensaver

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

    18. Faster access to High Performance power plan

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

    19. Custom theme improvements

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

    Windows Media Player

    20. Improved Internet Radio playback

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

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

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

    22. Cleaner Now Playing view

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

    23. Filtering content that cannot be played

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

    24. Resume from sleep

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

    25. Quieting Windows Media Player sync relationships

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

    26. Easier access to advanced settings

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

    27. Jump List improvement

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

    Device Stage

    28. Enriching the Device Stage ecosystem

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

    Sound UX

    29. Improving the headphone experience

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

    30. Increased audio reliability

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

    Windows Explorer and Libraries

    31. Improved header

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

    32. Reduced confusion with drag/drop

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

    33. Reviving familiar entry points

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

    34. FAT32 support

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

    35. Arrangement view enhancements

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

    Performance

    36. Improving performance through data

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

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

    Fig 3.

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

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

    Fig 4.

    Start Menu Open Times for Windows 7 Build 7033

    Start Menu Open Times for Windows 7 Build 7033

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

    - Chaitanya Sareen

  • Engineering Windows 7

    Feedback and Engineering Windows 7

    • 105 Comments

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    --Steven

Page 1 of 3 (67 items) 123