Web Devout tidings


Archive for July 30th, 2006

Internet Explorer feedback system a disaster

Sunday, July 30th, 2006

Late March 2006, Microsoft anounced the Internet Explorer feedback system, aimed to provide users with a way to submit and publicly view bugs and feedback suggestions much like the user end of Bugzilla. Unlike Bugzilla, this would not be a place for the developers to discuss and chart their progress, but it attempted to provide end users with similar functionality.

Introducing this kind of system was a very good move, since there had long been a feeling of distance between the Internet Explorer developers and the users. This kind of system would provide a centralized location for users to discuss issues, rate their importance, and provide workarounds. I have personally submitted 11 reports using this system and have provided information for several other reports. This system had the potential for being an incredibly useful resource for web developers searching for information on Internet Explorer issues, which for many amounts to a majority of the web development process. Perhaps most importantly, this system would give us some insight into whether or when the issues would be addressed by the IE developers.

And that is precisely where the system has failed. Report after report has been closed with “Won’t Fix” or “By Design”, implying the issue will be indefinitely ignored, often without any further explanation. And these aren’t simply minor preference issues, but things that frequently cause real problems in the design world.

Here are some of the issues that Microsoft has marked as “Won’t Fix” or “By Design”:

  • CSS borders aren’t supported on table-column (col) elements – “Won’t Fix”
  • CSS “inherit” keyword isn’t supported for anything but the “direction” property – “Won’t Fix”
  • CSS “input:active” isn’t supported – “Won’t Fix”
  • IE doesn’t pass Acid2 – “By Design”
  • No support for implicit HTML labels (<label>Name: <input></label>) – “By Design”
  • Object element unusable for images (always displays with scrollbars) – “By Design”
  • PNG images generated by Photoshop and some other graphics utilities are displayed off-color (PNG gamma correction isn’t correctly supported) – “Won’t Fix”

Before you panic, this doesn’t necessarily mean that they plan to never fix the issues.

For instance, the feedback system administration has adopted the practice of marking a report as “Closed; By Design” if it was filed as a bug and the administration thinks of it more as a feature suggestion. Ultimately, this depends on whether or not the issue is what the developers originally intended to happen or otherwise feel is expected behavior considering their particular implementation, regardless of whether or not it’s part of the standard or even documented by Microsoft. For us web developers, there often seems to be no difference at all between what they want filed as a bug report and what they want filed as a feature suggestion. In these cases, rather than simply changing the submission type to their preference, the administration closes the report and presumably expects someone to resubmit the report as the other type. This has caused considerable frustration among the users of the feedback system.

Furthermore, they seem to waver back and forth on what the terms mean. Sometimes, they resolve a report as “Won’t fix” when they just can’t get to it by the next version, while the official definition is “We know that we will not be addressing the reported issue, usually because it risks breaking the code in other, more serious ways or because the effort to fix the issue is not justified for the improvement.” At other times, they simply leave it as “Active”, despite the exact same explanation in the comments. Meanwhile, there is another resolution status called “Postponed” which is designed for this kind of decision, yet I haven’t seen it used.

Presumably due to lack of manpower for testing and moderation, Microsoft has announced that within the next couple of weeks they plan to close every report that has been in the database for over a month, asking users to manually reopen all reports that still apply in Beta 3, which will likely account for nearly all of the reports currently open. It seems the system as it is currently designed is unable to scale to reasonable levels and they are letting it collapse in on itself, then turning around and asking us to rebuild it on the same shaky foundation. They are making it incredibly difficult to use the system for its intended purpose, while seemingly not taking the feedback we give them seriously. This creates a very frustrating situation for users who take time out of their schedule to submit and validate reports.

The problem isn’t just the administrative process either. The system still requires you to register and log in before you can view a report. This makes it difficult to link to issues from other sites. It would be a bit more tolerable if the system would at least keep you logged in when you check the box to do so. Countless sites on the Web manage to keep you logged in upon request whether you’re using Internet Explorer, Firefox, Opera, Safari, Konqueror, or even lynx, but the Internet Explorer feedback system can’t manage to remember Firefox users who ask to stay logged in. Users who submit information find that they are unable to edit most of that information once it is sent, which has led to several reposts of the same issues simply to make corrections.

The service that the Internet Explorer feedback system attempts to provide is very much needed in the web development community. Here is some of the work that needs to be done:

  • Only require users to log in to submit content. Reports should be publicly viewable without registering an account.
  • The login form should remember users when they select the relevant options. This is Web Development 101.
  • The Validation form should allow users to check boxes of versions they have validated.
  • Resolution status should be separated into two distinct status indicators: report status automatically determined by the user validation system; and a (non-final) version indicator of when the IE developers hope to address the issue, if ever. Users, not the IE developers, should decide whether or not an issue still warrants being listed as “Active”.
  • No more “By Design” ratings. It is simply insulting when 6-0 users have verified the problem and it has a 5/5 average rating out of 10 votes. And when 8-0 users verify a problem with a 5/5 average rating out of 11 votes, “Won’t Fix” becomes questionable as well.
  • Allow the report submitter to change any of the original details of the report.
  • Provide a way for users to mark duplicate reports, maybe using some kind of voting system, and always provide a link to the original report when marking a duplicate.

It seems clear that the administration is incapable of adequately running the feedback system. This may be due to lack of dedicated resources, but that isn’t an acceptable excuse when it comes down to service quality for the users. I say turn the system over to the users. Let user content determine the status of reports. Let users correct reporting mistakes. IE developers should keep us up-to-date with their progress, but as long as it is a user feedback system, let the users decide what is still an issue and what the details of the issue are. At the moment, the company-run Internet Explorer feedback system feels as if it is designed and run by amateurs compared to the user-driven Bugzilla system. Microsoft needs to learn from the leaders in the field and deliver on their increasingly trite promises.

In the meantime, I will continue submitting content to the feedback system, despite the fact that it seems to be fighting me every step of the way. I encourage other users to petition Microsoft to improve the quality of their service by loosening their iron fist.