How To Provide Product Feedback & Suggestions For WPF CTPs and Betas

Candid customer feedback is a critical ingredient in software development in Microsoft. Teams are constantly working towards a better understanding of customer and partner needs. While face to face contacts result in valuable insight on customers' issues, I find that the most frank feedback comes from fora that give our customers a sense of anonymity or a sense of community. It is important that we keep the right mix, for, after all the platform's focus is on best understanding problems our customers face. That way we can provide them the most compelling solution to build off of.

There are multiple ways customers can provide feedback and suggestions for Windows Presentation Foundation:

• getting hold of that elusive Avalon developer in a conference like the PDC
• posting comments on an Avalon developer's blog
• posting on the WPF Newsgroup, or
• posting on the WPF Forum, or
• submitting suggestions or reporting bugs on the Product Feedback Center

The last three are open, public arenas conducive to searching for and submitting information. I highly recommend using the Product Feedback Center over the newsgroups and forums. Unlike the other two, items posted in the Product Feedback Center are routed into the Avalon team's internal bug database. And that's why it remains the most reliable way to get your thoughts across all the way to the feature owner (the feature team's bug triage alias, or the PM/Dev/Test owners). In addition, you can validate, vote and track suggestions & bugs. Your votes do help us in the feature team to prioritize issues.

Here are some best practices on providing feedback, no matter what the forum is:

1. Search existing items. Some issues occur widely enough that others have faced them before you. Upon searching for bugs with your symptoms, you can vote on them rather than enter an issue afresh. In addition, you can track reported bugs.


2. Provide a meaningful title. Concise yet meaningful titles help route your issues to the right teams the fastest. Without one of these, the initial reviewer must read through the bug description and make a best faith effort to understand exactly what feature area owns the issue. Given a platform like WPF and the inter-relatedness of features, this can be a hard thing to nail down. So on some occasions I've seen a bug goes from triage alias to triage alias until someone identifies it as their own. Meaningful titles also help you and others search for issues easily.


3. Provide clear steps to reproduce the bug. This is relevant if the issue you're reporting is a bug rather than a feature request. Providing crisp steps helps the feature team in its first step of validating the issue. Some tips:
   • Use an ordered list with one item for each logical step. This makes it easier to read, convey on the phone or via email
   • Mention if the problem is consistently reproducible or not
   • For install or setup issues, I recommend attaching the install logs or even relevant snapshots. Look in your %temp% folder for files with "dd_" prefixes in their names
   • For compile or build issues, I recommend attaching build logs. The MSBuild system supports logging with various verbosities (by using the /v: switch on the command line or setting appropriate level within an IDE like Visual Studio).
4. Provide environment information. Be sure to mention the build number or CTP name, product mix you have installed (e.g. "I installed WinFX Runtime Jan 06 CTP and Windows SDK Jan 06..."), your OS platform, CPU and bitness (e.g. "... on Windows XP SP2, Pentium III, x86"). Given that WPF is a presentation platform, it helps to provide information on your graphics card and if you have the latest video drivers installed.


5. Provide solution or project information.
   • Specify whether you're trying to build an application or a library.
   • Is it a browser-hosted app or installed?
   • Provide information on your MSBuild/Visual Studio/Sparkle solution or project (is it a single project or a solution with multiple dependent projects etc.)
   • Did you specify a UICulture in your project? What about the neutral language setting in the AssemblyInfo. file?
6. Tell us how the bug impacts your scenario or your product. This aspect, often ignored, is one of the key parameters that help the feature team decide if, when and how we should fix the problem or if we should just publish information on workarounds. Ordinarily crashes and data loss scenarios are easiest to prioritize, because of their impact. Some bugs however only show up in corner cases. But one man's corner case is another man's mainline scenario. So some context like this helps us immensely in making the right decision.

I hope these come across as reasonable guidelines. While my focus in this post has been primarily on Windows Presentation Foundation and allied tools/products like "Cider" and "Sparkle", these more or less apply to other products in Microsoft and elsewhere.

Thank you for your continuing feedback and support. You only have to look at the features that got added into WPF after our first public CTP, and you'll know we hear you loud and clear!

Tags: WinFX

Email this | Bookmark this