When we released the first IE9 Platform Preview, we talked about the importance of feedback. Since that first release last March, we’ve released six more platform previews, an IE9 Beta, and a bug-fix update to that Beta and the IE9 RC. We want to thank everyone who provided feedback during the last nine months. Sharing your experiences with the IE Test Drive and Testing Center while testing your sites for compatibility and trying out new features like Pinned Sites all helps make IE9 better. We’d like to take this opportunity to share with you the trends we are seeing in feedback, provide visibility into how we handle that feedback, and show how it is has affected the Release Candidate.
When we discussed our approach to feedback systems, we talked about our commitment to take action on every piece of feedback we receive. This approach is different than other feedback systems. The level of interest in the previews and Beta so far has been strong. At the time of this post, the IE9 Platform Previews have been downloaded over 3.3 million times, the Beta over 25 million times, and we’ve received over 17,000 bugs from the public via Connect. That is 23% more downloads than IE8 Beta 2 during the same period and over three times as much feedback as we received for the entirety of IE8—from Beta through RTM.
These numbers represent interest from customers, developers and enthusiasts around the world. Over 8,000 people have logged bugs on over 8,000 domains worldwide. More than 7,500 of these users are providing feedback for the first time with IE9. We welcome these new users, just as we marvel at those who have provided exceptional contributions. Two users, Wheels of Flames and the dees (registration required), have logged over 200 bugs each, while another three, iecustomizer, Taciturne, and FremyCompany, have each logged over 50. Wow! We cannot thank these and our other users enough for investing their time and effort.
We investigate each item of feedback for reproducibility and uniqueness. Unique reproducible bugs are ranked in terms of importance and severity—a process we call triage. Once we investigate and triage an issue, we update the status in Connect.
Some of the feedback we receive is about the feedback management process itself, and questions around what the different resolutions for reported issues actually mean. Here are the resolutions you’ll see on Connect, and what they mean:
Your feedback helps us make IE9 better and we appreciate it. We use the feedback that you provide to aggregate and identify your top issues. We tally the number of duplicate bug reports, number of validations (when users click “I can reproduce the issue too” on Connect), and the number of comments to identify the most critical user concerns. From there, one of the steps of triage is to determine if the feedback is a product issue (code defect), feature request, or general feedback. We read all feedback and assign it an action on the path to closure. Additionally, every week we look at the list of top issues as a team to ensure we are doing the right thing for our customer concerns.
When we talked about how we listened, learned, and refined the user experience, we noted that your feedback was critical to several of the major changes we made in the IE9 RC. We provided several examples of how user input from Connect, blog post comments, and other sources led to improvements in the browser. Feedback directly contributes to what we call “Design Change Requests,” which typically occur when feedback indicates that a design decision should be revisited. Whether they were feature requests or bugs, we took all of the top issues seriously, fixing all of the top five issues and seven of the top 10. Note that we fix these at various times throughout the product cycle – it’s important for users to test out each new Platform Preview and full browser build to verify that their issues are resolved and validate the improved quality of the product.
While we are pleased to be able to fix many of the top issues, in the end we won’t fix every issue reported. As we said above, there are a variety of reasons why we decide to not fix a reported issue. Some of these issues are external to IE, some may introduce security issues, while others may be limited in their scope of impact. Sometimes we receive conflicting feedback – while one segment of users may like the cut-off Back button, others may not. In all circumstances, our decision making revolves around delivering a quality default experience for all of our users.
Our continued request is that you download the IE9 Release Candidate, try the samples on the test drive site, and try your own sites. Visit your favorite sites, try out the new features we announced and changes we made to the browser frame, and send us feedback about your experiences. Developers, send IE9 the same markup that you send to other browsers and use feature detection, not browser detection, to alter behavior between browsers and versions, when needed.
The IE7 compatibility view built into IE9, which some sites may run in, does not offer the best performance possible. If you still have sites that run in IE7 compatibility mode we recommend that you move those to IE9 standards mode. We want sites to get the full performance benefits of IE9 that come with running in IE9 standards mode. We also want your feedback from handing IE9 the same markup you hand other browsers.
Thanks again for your participation in the Internet Explorer feedback program.
—Justin Saint Clair, Program Manager