Customer and Product Group PFC Issues

As the Product Feedback Center team plans upcoming releases, we have been brainstorming and prioritizing improvements to address the major pain points customers and product teams have experienced since the site went public at the end of June. Though the site has received much positive feedback overall, there are a number of issues to work out. These issues have been outlined below. Please let us know your thoughts on the issues listed and our prioritization.

Ranking

P1 - The way the popularity of bugs/suggestions is determined for the top ten lists on the Product Feedback Center home page does not accurately represent the importance or priority of an issue. The issues on the top ten list get increased visibility hence more votes, which keeps them on the list since we multiply frequency by average vote value. This system degrades the popularity measure to one of just frequency and makes the actual avg. vote value meaningless.We are currently working on a better algorithm – the real need is better stats reporting and more buckets. We should represent the most frequently voted on issues separately from the issues with high avg. vote value.

Search

P1 - Search currently only returns top 100 results. We should let users get to all results and we’ll use paging to not take perf hit until the user specifically wants to get to those results.

P1 - Customers want to see resolution, status and MS status displayed in search results. We should ideally allow the customer to select which fields they want displayed in the search results.

P3 - Customers want to see more results (choice of 25, 50, 100 e.g) per page for search results.

P3 – On the search result page, customers want to see a ‘modify search’ button that takes them back to their original query so they can modify it and search again.

P3 – MVPs gave feedback that the advanced search is hard to use. We need to revisit the UI design of this page and do usability testing.

Reporting

P2 - Show average MS response time on the Product Feedback Center site, preferably by product to set the expectations for customers.

P3 - Recognize/encourage community contribution by displaying top validators, duplicate finders, top posters of bugs MS fixed, etc.

P3 - Show more robust stats on bug trends such as weekly incoming, resolved, fixed, etc. An area dedicated to bug statistics should be made available to users.

Submission form improvements

P1 - OS and OS language should not be required for suggestions.

P2 - Display workaround authors. Customers want to see who post the workaround and be able to query all things posted by that author.

P3 - Customers want to the bug form to preserve indentation (via using code tag, for example) in ‘problem statement’ field. The format will make code snippet more readable. Current workaround is to use attachment.

P3 - Customers want to be able to change a suggestion to a bug or vice versa, for existing issue (currently you can change at filing time).

Notifications and tracking

P1 - Providing RSS feeds for common bugs/suggestions on a particular product/technology is one of the highest ranked customer requests.

P3 - Customers want to track and receive notification for discussion posts on bugs.

P3 - Customers want to add an entire product center to their tracking and receive emails notification when new issues are added to that product center.

P3 – Web Service to expose content.

Annoying bugs

P1 – Users receive invalid change notification on bugs because field irrelevant to Product Feedback Center are updated on the Product Studio side and the customer is notified of a change regardless.

P2 – Some discussion posts appear twice in the thread.

Attachment access restriction

P1 – Users should be able to mark attachments as “for MS eyes only” so files are not made public.

User interface

P2 - Customers report that the header is taking up too much space and pushes useful info down. Incidentally, it’s an old MNP look and feel. We should change it anyway.

P3 - Customers want to have a better navigation scheme than using browser back buttons.

P2 - Customers report that it’s not obvious that they change status (reopen) by using the ‘edit’ button. One way to solve it is to have a separate button for status change.

Browse

P1 - Customers want to be able to browse and drill down into areas. Browsing a tree-like structure for all the issues would be ideal.

My settings (personalization/customization)

P2 - Remember user setting using cookie or profile, so he/she does not have to enter values like OS every time I reported something

P2 - Customers want to see all the issue they contributed such as: ‘I reported, I voted for, I validated, I posted to…’

P3 – Log in based profile management and customization so users can select what they want to see on their home page after they log in, etc.

Messaging/Communication

P2 - MVP asked for a help entry that explains how an MVP can help, what they should or should not do, etc.

P2 - Several users asked about adding released products or other non-Whidbey products. We should have a messaging in place for this type of question.

P2 - Fairfox and Netscape display is not great. The appearance issue is often related to asp.net controls that we have little control over. We should have a messaging that does not make people feel “it’s Microsoft, they support IE and don’t care about other browsers.”

PRODUCT TEAM ISSUES

You may find interesting a detailed inside look at some of the issues product teams face in working with the Product Feedback Center...

General Administration

P1 - The biggest pain point for product teams with regard to Product Feedback Center is the slow turn-around on category and Product Center change requests. This model is not scaleable and the situation will be exacerbated as more Products are added to Product Feedback Center. This process should be automated via a robust set of administration tools that allows an admin to change add product centers, change categorization and other fields via a webform that validates changes on submission.

P1 - The administration tools should also allow admins to specify bug description templates per product/version/category and to add hints or tips that would appear next to the description field.

Suggestions

P1 - Suggestions don’t seem to fit well in the Product Feedback Center workflow that is geared heavily toward bug reporting. There is quite a bit of Microsoft bug resolution terminology that may not make sense to customers, especially in the context of suggestions. For example - what does it mean if a suggestion is resolved as “Won’t Fix” or “Postponed?” Internally we define “Won’t Fix” to mean “we’ll never fix this” and “Postponed” to mean “we will consider it for the next version, but it won’t be implemented in Whidbey”. Further, if we close a resolved suggestion, does that keep you from voting on it and continuing the discussion thread? Note: PM work on this will be complete by September 15.

Porting to PS improvements

P1 - For a better experience for internal users, the way a bug is ported into the Product Studio database should be improved.

Duplicates

P1 - When a bug is resolved as duplicate, the votes are not aggregated between the primary bug and the duplicates. This gives an inaccurate representation of the number of votes and average vote value. When a bug is resolved as duplicate to another bug, the primary bug should get all the votes from the dupe, and the dupe votes should be set to zero.

P2 - When a Product Feedback Center bug is resolved as duplicate to an internal bug, the internal bug is remapped to the Product Feedback Center bug so the customer can receive updates. This is great however, every time the bugs are synced, we overwrite the repro steps of the PS bug with those of the Product Feedback Center bug. This means we overwrite the repro steps that were created internally. We should not overwrite repro steps in this scenario.

Where’s my fix?

P2 - When we tell a customer we’ve fixed their bug or suggestion, they want to know when that fix will be available. The problem is, we don’t have a great way of communicating what build each fix will be in. Currently it’s sometimes even difficult to communicate internally which fixes will be in which drops to internal partners.

History

P3 - Currently there is no way to edit the description history of a bug or suggestion. This means if a Microsoft employee submits text that is inappropriate (such as inadvertently divulging non-public/confidential) information about a project or product. The only recourse we have is to hide the issue all together.

Attachments

P2 - Currently attachments posted on the Product Feedback Center are not imported so product teams have to download them from the front-end site manually. We need to enable automatic virus scanning on the attachments to port them into our internal Product Studio database.

Marie Hagman

Visual Studio Core Team