Overhauling the Visual Studio feedback system
During the summer, we refreshed the experience for sending feedback on Visual Studio. It marks the first in a long row of changes coming to the Visual Studio feedback system. The result will be a more engaging experience that is also faster and more user friendly.
The feedback tool helps us fix more than five hundred customer-reported bugs and feature suggestions in each update of Visual Studio. It’s an important part of our development process, and now it’s time for an overhaul.
Over the years, we’ve collected feedback on the feedback system from both Visual Studio customers and from our engineers who investigate the customer feedback. This has given us a great starting point with a good understanding of what worked well and what didn’t work so well.
For practical reasons, we started by moving the reporting tool to a browser-based implementation. You still send us feedback using the same commands under the Help top-level menu inside Visual Studio. Clicking Report a Problem… or Suggest a Feature… will now open your default browser to the feedback tool.
Moving the feedback tool out from being a modal dialog inside Visual Studio to be browser based has some benefits. Since it’s in your default browser, your normal browser workflow of copy/pasting, searching, using extensions, keyboard shortcuts etc. stays intact when filling out the bug report.
Also, the modal could sometimes cause problems when recording traces and taking screenshots as part of reporting a bug. With the modal dialog now gone, this is no longer an issue. Finally, the browser experience will allow us to innovate more rapidly without dependencies on the Visual Studio release schedule.
The previous feedback flow consisted of multiple wizard steps. That made it challenging to know exactly what information to give and how long it would take to finish the bug report. The new tool keeps it all on a single page, making it clear what to fill in.
When writing the description, you can take full advantage of markdown to make it as clear as possible. A new impact selection dropdown helps the Visual Studio engineering team better understand the nature of a bug, which will help them fix it.
Recording traces is one of the most helpful things in a bug report, because it gives the engineering team a much clearer picture of where the issue occurs in the code. We updated the process of recording to happen completely asynchronous so that you don’t have to wait for the recorded traces to finish before you can submit the bug report. It will automatically upload those traces in the background after you submit – even if you close the browser.
This feature is almost complete and ships very soon.
To follow up on your problem reports and feature suggestion, go to the new My Feedback page. Access it from within Visual Studio from Help -> Send Feedback -> My Feedback… or from the browser after you reported a problem or suggested a feature.
From My Feedback you can quickly check the status of your tickets or, if we have sent the issue back to you, provide extra diagnostics information to help us investigate the issue.
First of many updates
We started by updating the reporting flow, but we have many more updates to come in a wave of new features, tweaks, and redesigns. Customer suggestions drove many design decisions and we’ve been able to complete a high number of them with this first change. In the months to come, we’ll be able to complete a lot more as we start rolling out more updates. In the end, you’ll experience a faster and more user-friendly system that is more engaging to use.
If you have any ideas for improvements, please let us know in the comments below or on Developer Community.
You wrote that I have to click on ‘Help -> Send Feedback -> My Feedback’ in VS to get a list of my Feedback, but my VS 2017, Version 15.9.26 only has ‘Report a Problem’, ‘Provide a Suggestion’ and ‘Settings’ in ‘Help -> Send Feedback ->’
So I have no ‘My Feedback’ Button and Can’t view my Feedback Anymore.
You can still view it on the Developer Community by clicking your name in the top right corner and select My Feedback.
Overhauling the Visual Studio feedback system? For what?
Visual Studio feedback system needs attention and responses. No close for feedbacks, bug or features request, without any answer.
Nothing about the most voted issues to restore the old new project dialog and the old start page in order to make Visual Studio 2019 useable. There are a lot of feedbacks with this case, one of them with 123 votes. All the negative comments in blogs like https://devblogs.microsoft.com/visualstudio/redesigning-the-new-project-dialog are claimming LOUD and CLEAR to restore the old new project dialog. But the last answer from Pratik Nadagouda, about 8 months ago, is that we are fixing and adding a simple browse experience as a toggle to recent templates on the left hand side pane, a fix that nobody request. The resquest is to restore the old new project dialog and the old start page in order to make Visual Studio useable again.
But there have been no more answers.
Things like this, that are completely ruining the entire developing experience, are very, very frustrating.
I think you can continue complaining in this Developer Community thread, I don’t agree with the majority of the comments over there as I really like the new Project Dialog, but you guys have a point on having a choice to select what experience should use, the old tree view for those with a large experience with VS, or the new dialog window for new developers: https://developercommunity.visualstudio.com/idea/401508/vs-2019-preview-new-project-dialog-is-unstructured-1.html
I’ve been working with Visual Studio since VS 6 with C++ and VB and I’m really comfortable with the new design, it’s been more than a year to get used to it. But you’re right, you have to have your voice heard and have the right to choose.
You know the funny thing about your comment is that several educators commented on how much harder it was for new users to find what they were looking for in the new design. They were constantly having to go over and help them select the right project type. This is understandable when the new design forces back into the result set project types that were explicitly eliminated by the filter/search.
I agree with @Chuck at 101%
THIS IS THE BIG BIG PROBLEM of the site.
But seems they play with words and paper … not with reality 😉
I wroted about this few time this in developercommunity … but seems there is no a leader with a clear vision in this community.
All reply: “thanks” “thanks” but no one close oolder issue, some on VS2015 !!!, no one change the way of this site interact with the user.
Thank you for putting this onto the table for discussion.
I can’t say how much I HATE this new “New Project” dialog and the start screen. Both of them are extract demonstration of bad designs and bad customer experience management. So many programmers have posted negative comments within the recent yearS–yes, we can use the plural form of YEAR now, that comment thread had been posted on Dec 06, 2018, quite more than one year before!
Those “new design” were purposed to help new users to find out more. But quite ironically, several teachers’ feedback said that it was much harder for their students to learn to use them. Professional programmers who had been working with VS for decades posted their frustrated experience either. Both newbies and professionals were not benefited. Nevertheless, zero valid improvement has been made.
It is not the problem of the feedback system. It is the problem how you VS team in MS respond and manage the feedback from users.
Stop making ineffective changes, please.
Recognize and face the problems, please.
Sometimes it is difficult to show a problem with just a static screen shot and it would be better if a small video could be recorded while demonstrating the problem.
Peter, that’s a great idea. Do you mind creating a feedback ticket for it, then I’ll make sure it gets on the backlog. The reason I’m asking you to open the ticket is so that you can get the updates as they happen.
I hate to say it, but it’s not just about the technical implementation, the team and staff handling feedback are not great (sorry, but it’s true):
1) Too often comments by the poster are not taken on board (e.g. when the raiser of the bug points out that they cannot use a certain compiler, typically for business/validation reasons, but the responder at Microsoft doesn’t take that on board and just blindly tells the person to “try the latest compiler”).
2) Vague responses – e.g. “This is fixed in our latest release”. That’s not helpful. When responding, the response should EXACTLY say which version (or later) has the fix in (e.g. 15.8.2 or _MSC_FULL_VER >= 192811111 etc.) “Latest releases” are a moving target and a lazy answer. Be exact in your answers.
3) Too often the “feedback bot” just kicks in with responses along the lines of “There’s been little activity on this issue in x days. Therefore it’s unlikely to get fixed”. This is rubbish. I’ve seen this with crashing bugs and code generation issues.
Fix the staff and the customer support process – the feedback tool is secondary.
We’re looking at the entire system all up, including internal processes on how feedback is handled. It’s not limited to the public facing website only, though this blog post only talks about that aspect. I should write another post about the other changes too.
I agree with Mike. There are some bad canned responses, but the worst one I see is where it’s closed due to “lower priority” (paraphrased): “We’re closing this right now, because we’re working on so many things, and we don’t have time to address it.” Again, that’s slightly paraphrased, but the response is along those lines. Just because you’re busy doesn’t mean you should close the bug straight away. I remember when VS 2017 came out, it was astonishingly buggier than any prior version, and many bugs reported were closed immediately with this response. Yes, it’s true that if you release software that’s crashing left and right, you have some much higher priorities to deal with, but don’t close legitimate bugs…leave them open.
It is something we are looking into addressing internally. We fix over five hundred customer reported issues per update to VS (625 in latest update), but we can’t fix all of them. That could be ones that are expensive to fix with already existing workarounds. In our new guidelines we talk a bit more about this. So, we must prioritize among them and fix them in the right order of impact.
In numerous studies we’ve done, it’s been clear that users want to know if their problem is going to be fixed or not as early as possible. They often state that the worst thing is for a problem report to stay open for years while nothing happens. On the other hand, the frustration you’re experiencing is also real and shared among many users, so getting this balance right is something we’re constantly striving for.
Thank you for keeping us to the fire on this matter. It’s important to us and we really want to do the best we can, though it sometimes doesn’t seem that way from the outside.
PS, we changed the canned response you are referring to very recently. It doesn’t suck as bad now 🙂
I 101% agree with Mike.
That is the point!
Seems that you (MS) want treat a seriously injured person with a band-aid 😉
Sincerly I report erros and bug, but it’s very very hard to help voting or adding notes to other issue because is a MESS browsing the issue and the suggestions!
May be you (MS) have another UI ?
so many genuine feedbacks and suggestions are still hanging without any sort of proper attention/response. In VS2019 so many new useless features are being added in every release and at the same time, some core burning issues are being overlooked. Such ignorance is demotivating us to report prob or give feedback/suggestions. one such example is the VS2019 new project dialog box. How long will it take to provide an option to switch to the old or new dialog and use VS telemetry to know how many developers are really using the new dialog? Why forcing something which the majority dislike the idea from day one.
I like the new browser-based Feedback with a hook into Visual Studio. Very nice, thanks! Is there also an official word on the policies governing these “ideas?” For example, it used to be that you closed them when they didn’t make it onto the Roadmap for a given release, even if they were quite popular. I believe I saw you mention somewhere that this policy has changed? I totally agree with this BTW. Good ideas are good ideas. Can we resurrect some of the previously closed “good ideas” above a certain threshold of upvotes perhaps?
Thanks for the kind words on the new browser-based tool. While it is true that we used to close ideas that we couldn’t get to in the short term, we no longer have such a policy. We’re even making it possible to request re-activation of closed feedback tickets and that you can continue voting on closed tickets. Recently, we published guidelines that includes how we handle incoming feedback.
Please give lots of love to the Developer Commuity. It’s a very disappointing experience.
– Ctrl-Z undos more than one would expect, sometimes full paragraphs
– Ctrl-Y doesn’t always redo
– Ctrl-K doesn’t add a link, like in most editors
– The service reps aren’t as educated or helpful as they need to be
– Search isn’t great
– There are often multiple threads reporting the same issue, but they are all marked as “Not enough information” or “Low priority”
– Issues are closed as stale, while the users were waiting for the reps to respond
– Issues can be closed as “Low priority” and don’t allow further voting
– Because of some of the the above, votes are not consolidated and thus reappearing issues/feedback end up going ignored
Thanks for your comment, Dan. We’ll make sure to give the Developer Community a lot of love.
The issues about closing as stale or low priority, no voting on closed tickets, and duplicates that doesn’t consolidate votes are all issues we’re looking into addressing. We’ve already taken several measures with more to come soon. I’ll write more about what we’re doing in these areas in a different blog post.
Have you taken into account that the developers using your product have an actual job, other than providing you with free QA services, and don’t have time to browse various tickets looking for related issues to upvote. Just dealing with the issues themselves takes more of our time than we actually have.
I agree with Dan
Hey @Mads Kristensen do you have seen how many comments about the real USABILITY of the site?
It’s years that someone puts comments like these in DevCommunity (I surely) but no one have followed they.
I hope that the comments in this page can stimulate per boss of the DevCommunity to wake-up him to listen people that works every day dvelopping code for the real-world and have a great real-world ideas.
Someone known who’s the BOSS of Developer Community?
I strongly agree to the other comments:
It’s not the feedback system itself that needs overhauling – it’s the attitude of certain teams and the way how they are misusing the feedback system to keep their statistics looking good. I had made pretty mixed experiences. In rare cases even high quality responses in a timely manner.
What’s not acceptable IMO is that
– Sometimes, employees are hiding themselves by letting status decisions appear as being made by the “Feedback Bot”, even though, it’s obviously a human’s decision
– Reported issues are marked as “duplicate” of issues that are already closed
– A detailed bug report is suddenly converted into an “Idea”, clearing all votes and not getting responses anymore (even though it’s been confirmed and reproduced)