Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a generic code fixer for navigating the URL of a diagnostic #42103

Closed
terrajobst opened this issue Mar 2, 2020 · 14 comments
Closed

Provide a generic code fixer for navigating the URL of a diagnostic #42103

terrajobst opened this issue Mar 2, 2020 · 14 comments
Labels
Area-IDE Feature Request Resolution-Won't Fix A real bug, but Triage feels that the issue is not impactful enough to spend time on.
Milestone

Comments

@terrajobst
Copy link
Member

The DiagnosticDescriptor has a HelpLinkUri property which is used by the IDE to render a hyperlink in the error list:

image

However, this is quite subtle and I've seen many people not noticing this. In my own analyzer, I've added a code fixer that offers to browse to the location:

image

However, my code fixer is specific to my own diagnostics. It might help to provide a built-in code fixer that offers this capability for all diagnostics. Especially because the priority of this fixer should probably be lower than other code fixers but the ability to tweak priorities wasn't exposed last time I checked.

@terrajobst
Copy link
Member Author

Tagging folks who have an interest in this space: @mikadumont @mavasani @CyrusNajmabadi

@sharwell sharwell added Area-IDE Feature Request Need Design Review The end user experience design needs to be reviewed and approved. labels Mar 3, 2020
@jinujoseph jinujoseph added this to the Backlog milestone Mar 5, 2020
@terrajobst
Copy link
Member Author

Any chance we could prioritize this for .NET 5? This is part of the better obsoletion work.

Documentation pages are easily accessible. Developers must be able to go from the diagnostic in the error list straight to the documentation that provides the details.

My concern is that the hyperlink in the error list isn't discoverable enough.

@CyrusNajmabadi
Copy link
Member

My concern is that the hyperlink in the error list isn't discoverable enough.

Any way we could get data on that? it seems pretty clear to me. it's blue. it's got an underline. i know my mouse has gone over it many times and seen it light up. So i'm totally biased, but even not being at all part of the design there, it was immediately obvious to me what that was.

@terrajobst
Copy link
Member Author

terrajobst commented Mar 31, 2020

Any way we could get data on that? it seems pretty clear to me. it's blue. it's got an underline. i know my mouse has gone over it many times and seen it light up. So i'm totally biased, but even not being at all part of the design there, it was immediately obvious to me what that was.

We have implemented said fixer in our platform-compat tool because based on customer interactions it was quite clear that many didn't realize that the guidance was available by clicking on the error code in the error list. Can I quantify that? No. Could we have done a user study? Yes, but implementing the fixer was tremendously cheaper than that...

@CyrusNajmabadi
Copy link
Member

The problem is that we may have many items in that list. It's common to have 10 or more fixes offered for a variety of issues that may be on that line. I'm really hesitant to have this item here as it would effectively double the size of those lists.

We already have feedback that we even have too many items already, and we spent a ton of timing getting down to even the set we do offer. Adding more seems not great. I think this is the standard discoverability/intrusiveness problem. We can make things more discoverable by putting them more in hte user's face. But once they're discovered, now what does that do the rest of the experience? How does htat impact users who don't necessarily want these? etc. etc.

Maybe we should rename the bottom bucket and make it a general catch-all for this sort of thing. i.e. if you want more info you go into this:

image

And you can suppress/config/about/report-issue.

@terrajobst
Copy link
Member Author

Could we collapse them into a single menu item with sub items, like

@mavasani
Copy link
Contributor

mavasani commented Apr 1, 2020

@terrajobst @CyrusNajmabadi I can implement this as per Immo's suggestion. I prefer keeping "Help Link/Guidance" menu separate from "Suppress/Configure issues" - they seems separate actions. @mikadumont for her views.

@mikadumont
Copy link
Contributor

I agree with Cyrus that the hyperlink is visible enough.

@CyrusNajmabadi
Copy link
Member

I'm ok with a new item in the list if it's a single item at the bottom (likely below suppress/configure). But my gut goes with: i would prefer to do nothing.

@mavasani
Copy link
Contributor

mavasani commented Apr 1, 2020

I think at this point we clearly need more customer data to move forward on this...

@svick
Copy link
Contributor

svick commented Apr 3, 2020

@CyrusNajmabadi

it seems pretty clear to me. it's blue. it's got an underline. i know my mouse has gone over it many times and seen it light up. So i'm totally biased, but even not being at all part of the design there, it was immediately obvious to me what that was.

It's blue, but in its own column, so I think the color doesn't stand out as much as it would e.g. inside a paragraph of text. And it's got an underline only when you hover over it or when it's selected.

But most importantly, you can't quickly differentiate between a link that will send you to the actual official documentation from a link that will just google the error for you (and it doesn't even use Google for that). And since the latter is the case for many errors, I suspect many developers become "blind" to those links, after trying them a few times and finding them not useful.

So I think it makes sense to have a more obvious way of providing a link that is actually useful.

@mavasani
Copy link
Contributor

mavasani commented Apr 3, 2020

So I think it makes sense to have a more obvious way of providing a link that is actually useful.

Note: this issue is not about providing a different link. The link is actually not controlled by the error list or the editor - it is provided by the diagnostic provider (compiler or analyzer that produced the diagnostic also provides the help link). This issue is about making whatever link that was provided to the IDE more discoverable.

We already have separate issues tracking improving the help links for compiler diagnostic and IDE analyzer diagnostics. See #40863 and #41324

@sharwell
Copy link
Member

Design review conclusion: We should add a hyperlinked diagnostic IDE to the Quick Info popup for the messages presented by diagnostics. At the time diagnostics were first added to the error list, we did not have the ability to hyperlink items in Quick Info. That has since changed, so we can leverage the new functionality to serve two purposes:

  1. It will be easier to see which messages in Quick Info are related to which diagnostic IDs
  2. It will be possible to navigate from Quick Info to the help link provided for a diagnostic

@sharwell
Copy link
Member

sharwell commented Apr 27, 2020

Closing this issue in favor of #43728. This issue is marked as Won't Fix as presented, but the desired end goal should be achieved through the alternative proposal.

@sharwell sharwell added Resolution-Won't Fix A real bug, but Triage feels that the issue is not impactful enough to spend time on. and removed Need Design Review The end user experience design needs to be reviewed and approved. labels Apr 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-IDE Feature Request Resolution-Won't Fix A real bug, but Triage feels that the issue is not impactful enough to spend time on.
Projects
Archived in project
Development

No branches or pull requests

7 participants