Dependencies Node UX improvements

[cartermp]

This is a tracking issue for features related to the UX of the dependencies node:

• Show target frameworks in their own group, not under SDK (PR FrameworkReference support #4928)
• Only show dependency warning icon when there's a problem (Don't show dependency warning icons while waiting for design-time build #5044)
• Diagnostics not shown under packages in the dependencies node (Diagnostics not shown under packages in the dependencies node #3780)
• Diagnostic severity not shown under packages in the dependencies node (Dependencies Node does not display Error icon where expected #2582)
• Group package/project dependencies by provider type (Group package/project dependencies by provider type #1255)
• Tree/graph nodes don't collapse on update (Dependencies tree should not collapse on update #6012)
• Provide feedback that dependencies node is populating (Provide feedback that dependencies node is populating #5045)
• Use tool tip for information about dependencies node warnings (Use tool tip for information about dependencies node warnings #4357)

[abpiskunov]

I like the spinner. Nodes will not be expandable anyway if there no child items in the snapshot.

[Pilchie]

One note for @davkean's sake - VS also has the concept of "Extension SDKs". If any of those are at play, there should also be an "Extension SDKs" root node.

[drewnoakes]

I've seen a spinner for folders within projects, though don't know how that happens yet.

[DamianEdwards]

What is the semantic difference that's worth highlighting in this case between Framework References and Shared Frameworks? I'd argue they're the same thing when it comes to visualizing them here. Also, can we make the nodes interactive at all, e.g. supporting deletion, selection, property editing via the grid, etc.

[drewnoakes]

• Dependencies node shows with a warning icon until restore is complete #2079 The visual effect of the dependencies node makes customer to wait on it #3430 warning icon while restoring
• Non-informative warning icons in solution explorer #2257 Dependencies node fails when ReferenceOutputAssembly="False" on ProjectReference #2653 Use tool tip for information about dependencies node warnings #4357 general confusion about warning icons not showing tooltips or error list items

[cartermp]

@DamianEdwards

What is the semantic difference that's worth highlighting in this case between Framework References and Shared Frameworks? I'd argue they're the same thing when it comes to visualizing them here.

In this case, I'm calling for Shared Framework and Framework Reference to be distinct sub-nodes. If a given project type gets its references from only one or the other, we should only show that sub-node unless one is added. Otherwise, both would have the same tree view for displaying their contents.

Also, can we make the nodes interactive at all, e.g. supporting deletion, selection, property editing via the grid, etc.

I think that's a separate issue that I'll have to think about. Having a way to manage these various kinds of dependencies beyond the project file (and in NuGet's case, the NuGet UI) may be helpful. What sorts of items would you feel are good for CRUD operations?

[DamianEdwards]

@cartermp still not really following. What is the difference? A FrameworkReference is a reference to a shared framework, so I'm not sure why they'd be separate at all.

[cartermp]

Gotcha. Sorry, just not caught up on what FrameworkReference is yet. So it seems like we'd have just one section and name it either "Framework References" or "Shared Frameworks". Which is the nomenclature we wish to push moving forward?

[DamianEdwards]

I think it's fine to just split the difference and say "Frameworks" for now. We can adjust as necessary.

[davkean]

I would consider an alternative design; the spinner on the outer node makes entire tree "feel slow" even though I may never open the dependencies node. I'd consider a design where we only show a spinner on the individual references items as you expand them. They might not have children, but it's a pattern that we use elsewhere, including Explorer, Server Explorer and SQL Server Object Explorer. These all add a "fake" sub node, and remove it when the data is loaded and there is no children.

This would fall in line with the work we plan on doing to delay load the data unless someone expands them.

[abpiskunov]

I can see why people would have a "feel slow" impression, since spinner means "Loading" in general. It can be something else not exactly that spinner.

Though I believe that putting "spinners" on lower level nodes alone (without top level Dependencies node) is kind of useless since vast majority of users have their Dependencies node closed. When you compare this behavior to other things like Server Explorer etc, existing logic is not necessarily better. In fact it can not even be compared with Solution Explorer, since in Server Explorer actionable nodes are lower level nodes them selves, i.e. user would want to keep root node open; when in Solution Explorer actionable nodes are files and Dependencies is (almost) always closed.

I know there are many opinions and we did have lots of conversations years before for Dnx and for this existing Dependencies node, thus I think we need to define the end goals for this redesign and try to adjust all proposals so they fit those goals:

a) there should be a way to indicate that something is wrong in Dependencies, it should be easily accessible and understandable to users at all times without opening Dependencies root node and without keeping Error List opened
b) there should be a way to indicate some progress for Dependencies node, i.e. dependencies are being updated;
* it should be clear to users that they can continue doing their routine work, however it also should be clear if some actions (like build) are blocked by some dependencies updates (like NuGet)
* When state changes the indicator of choice (icon/spinner/caption/anything else) should not jump/change too frequently to avoid noisy effect
c) any state indication should be propagated down to the root cause of the state changing node, i.e. if some node is being updated then progress indicator should be displayed all the way down to that node in case user would want to dig down and see what causing the state change

Those points above are coming from previous discussions. Also i would include NuGet team here since Restore plays pretty big role in Dependencies state changes and still missing good progress indication.

[Pilchie]

We should consider scheduling a UX review to talk about this. @jjmew do you want to set that up?

[jjmew]

We should consider scheduling a UX review to talk about this. @jjmew do you want to set that up?

Yes, I can do that. Additionally I think that we should agree on what metrics we are trying to move. Then we can run a experiment putting the loading spinner in different levels (or even not having it).

@cartermp @Pilchie what is the time frame that we have in mind to have a UX review?

[cartermp]

Not sure if there's a particular metric established so far, but my thoughts are:

For the redesign of SDK --> References and not duplicating stuff in the NuGet tab...

• Better perf if that's applicable?
• Simply having an accurate representation of the product that doens't leak implementation details

For the loading UX...

• Less bug reports about icon confusion
• Faster time to interaction in the editor

Though I'm not really convinced this would help move the needle on having a faster time to interaction, since user studies I've conducted so far indicate that people aren't paying too much attention to the node.

[drewnoakes]

user studies I've conducted so far indicate that people aren't paying too much attention to the node

If it starts animating, they will.

@jjmew is there a way to factor the perception of performance into measurable metrics in such an experiment? There's a lot of psychology in user satisfaction around performance. For a good example of what I'm talking about, see the recent trend of using skeleton screens in place of wait spinners.

There's a lot the user can still do while dependencies are loading. Showing potentially many spinners on screen would, I expect, increase the perception of slowness (and potentially actually increase the actual slowness due to animation). I wonder if we can measure this.

[Pilchie]

I think we can schedule a UX review sometime in January, I don't think it's urgent.

For metrics, I think "Time to first interaction" is probably the best one. Anecdotally, I know a bunch of people wait until the see the exclamation going away before doing anything. @davidfowl talks about it all the time.

[abpiskunov]

Animation is unnecessary it indeed could be annoying, however state indication is. We can get other icons or small adornment next to the node instead of spinner , anything else...

[davkean]

The background task center is where we putting background progress of tasks and the incremental state of project load.

When we delay load data from top level nodes downwards, we are going to have to put a spinner on those nodes anyway.

[davkean]

The other thing, it's not clear what this "progress state" of the node is actually tracking:

• It's not tied to or tracking NuGet restore
• It's not tied to or tracking design-time builds
• it's not tied to or tracking when Roslyn has references that its showing

If it's only tracking "when does the node have up-to-date data", we may as well only show the progress when the user digs into the data.

[etbyrd]

Some previous discussion: #2248

[jjmew]

user studies I've conducted so far indicate that people aren't paying too much attention to the node

If it starts animating, they will.

@jjmew is there a way to factor the perception of performance into measurable metrics in such an experiment? There's a lot of psychology in user satisfaction around performance. For a good example of what I'm talking about, see the recent trend of using skeleton screens in place of wait spinners.

There's a lot the user can still do while dependencies are loading. Showing potentially many spinners on screen would, I expect, increase the perception of slowness (and potentially actually increase the actual slowness due to animation). I wonder if we can measure this.

Yes, there are ways to extrapolate if perception has change. I do want to call out that If perception changes but behavior doesn't then it wasn't that helpful. At the end of the day we want to motivate behaviors. For example having spend less time waiting before their first action. We can do a brainstorm to think about metrics.

[jjmew]

I think we can schedule a UX review sometime in January, I don't think it's urgent.

For metrics, I think "Time to first interaction" is probably the best one. Anecdotally, I know a bunch of people wait until the see the exclamation going away before doing anything. @davidfowl talks about it all the time.

sounds good, I will schedule it.

[drewnoakes]

@cartermp I've broken the various actionable ideas here out into their own issues and converted this into a tracking issue. Please take a peek.

[cartermp]

@drewnoakes I like it!

[drewnoakes]

Closing this as we have issues for the ideas presented here.