Thanks for your Feedback!
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.
The Numbers
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.
More on our Feedback Systems
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:
- Fixed: The engineering team reproduced the issue and has fixed it in this release. This is clearly our favorite resolution.
- Not Repro: The engineering team could not reproduce this issue. Some issues are very subtle and hard to reproduce across different systems and Internet access configurations. Help from the community here is crucial. (If you can still reproduce the problem, please provide step-by-step details and additional configuration information by attaching an IEDiag log file and a Fiddler trace while reproducing the problem. If possible, please try to reproduce on a second machine.)
- By Design: The engineering team expects the behavior noted in the report. By Design means we understand the feedback and the behavior is deliberate. An example of an issue that we consider By Design is that the Platform Preview does not install on Windows XP. IE9 has security (e.g. protected mode) and graphics (e.g. DirectX) functionality that requires other components not available on Windows XP, an operating system that first shipped in 2001 with IE6. Because of the decision to not support Windows XP, the issue of IE9 not installing on it is “By design.”
- Won’t Fix/Postponed/Feature Suggestion: The engineering team investigated the issue or suggestion and will not address it in this release of IE. We will consider the issue for the next product cycle, especially if the severity or frequency of the issue changes. An example here might be work that is out of scope for the current release (e.g. MathML support), or features that do not fit in the overall context of the release.
How it Comes Together
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.
Top 10 Concerns in IE9 Beta
| Feedback ID | MS Connect Title | Duplicate Reports | Validations | Community Comments | Resolution Description |
|---|---|---|---|---|---|
| 598728 | [REQUEST] Make IE9 URL-BAR better please IE team! | 283 | 351 | 177 | The core of this issue is the desire to see more of the address and tabs for users who open many tabs. In response to this feedback, with the RC we added a feature to allow you to separate the tab bar from the address bar. |
| 599845 | Loading Circle | 298 | 252 | 138 | Users found that the spinning circle in the tab stopped before the page had fully loaded. We’ve fixed this in RC. |
| 598400 | Download speed not shown | 169 | 198 | 80 | Users wanted to see the speed of multiple downloads in progress. With RC, we’ve added this feature to the top level of the Download Manager. |
| 598389 | Highlighting text and releasing the button over a link clicks the link | 123 | 117 | 59 | This issue was fixed in Platform Preview 6 |
| 598102 | Please return my Menu Bar | 102 | 131 | 36 | Users couldn’t find the Menu bar (which was found using the Alt key in the Beta). With the RC we’ve updated the right click interface in the title bar and tab bar to allow you to turn on the Menu bar permanently. |
| 600623 | Feature Request – Move Home, Favorites, and Tools buttons | 88 | 87 | 30 | With RC we addressed the primary user concern around the option to have a dedicated tab row along with showing the menu bar. With these options, users can get the favorites and tools option in the top-left region. |
| 598091 | Websites cannot be pinned to taskbar it taskbar is on the left of the screen | 88 | 60 | 16 | When users had their Taskbar anywhere other than the bottom of the screen, attempting to pin a site by dragging a tab was interpreted as an Aero Snap command for a side-by-side view. With the Release Candidate, the initial drag to a non-bottom aligned Taskbar is interpreted as a pin command – if you then drag your mouse away and back over the Taskbar, it will be interpreted as a Snap. |
| 598615 | Back button is drawn incorrectly | 82 | 69 | 39 | The clipping of the Back button is By Design. It is designed to provide some visual tension for the left side of the browser, balancing out the three buttons on the right side. It emphasizes the importance of site content over the browser frame. |
| 598257 | spellchecker | 57 | 79 | 44 | We are not addressing this feature request in IE9, but will be considering it for future versions. |
| 598737 | Show Desktop not showing Sidebar Gadgets | 52 | 77 | 26 | Gadgets should always remain visible on your desktop, even when you hit the Show Desktop button. We fixed this issue in the RC. |
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.
Looking Forward
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