Propose NuGet.org portions of TFM spec #10573
Conversation
drewgillies
requested review from
agr,
anangaur,
chrisraygill,
dannyjdev,
jcjiang,
joelverhagen,
JonDouglas,
loic-sharma,
lyndaidaii,
ryuyu,
shishirx34,
skofman1,
zhhyu and
xavierdecoster
| ### Solution | ||
|
|
||
| - A .NET developer can view Frameworks of a package on NuGet.org: | ||
|  |
There was a problem hiding this comment.
For new users, these may be rather opaque strings. Can we link to a "good" doc that the .NET team has (don't know which one) that explains these various frameworks.
Said, if I install the .NET SDK or Visual Studio and I want to hack away at a project, what good first document can I read to start understand this wonderful ✨ world of TFMs we have.
There was a problem hiding this comment.
I'm sorry, I now see Unresolved questions. This covers some of my questions.
There was a problem hiding this comment.
There was a problem hiding this comment.
Great--I've added this to the Target Framework List section:
Let's link to an explanatory document for any frameworks we expose here, for example: https://docs.microsoft.com/en-us/dotnet/standard/frameworks#latest-versions
@jcjiang--I'm not entirely sure how this would need to look in UI. I initially asked you for a mockup, but I think it would just be the first text we see when expanding. Might need your help on wording though, and anything else we might want in there.
There was a problem hiding this comment.
Makes sense. Ping me when you are messing with wording, happy to help there.
| ### Success: How do we know if we’ve solved this problem? | ||
|
|
||
| - By gauging excitement/disappointment after blogging about this feature & analyzing sentiment on Twitter/GitHub/DevCom/etc. | ||
|
|
There was a problem hiding this comment.
- Compare the before and after numbers for error messages due to TFM incompatibility. Is there a noticeable decrease? If so, how long after the feature was rolled out for the decrease?
Not a perfect metric, but some data to show
There was a problem hiding this comment.
Based on the convo below, how many people click open the section to expand.
There was a problem hiding this comment.
Added this metric to the spec.
| ### Solution | ||
|
|
||
| - A .NET developer can view Frameworks of a package on NuGet.org: | ||
|  |
There was a problem hiding this comment.
Makes sense. Ping me when you are messing with wording, happy to help there.
| - A .NET developer can view Frameworks of a package on NuGet.org: | ||
|  | ||
|
|
||
| - We will have the list collapsed by default in order to track popularity. |
There was a problem hiding this comment.
At an earlier point in time (about ~1 year ago), we did some analysis on what frameworks does a package really support vs what frameworks are declared in the dependencies section and we found that for about 95% of packages, these are a 1 to 1 relationship.
Have we consider making that more apparent instead? In the interest of saving some vertical space/introducing a new concept that's already covered in most scenarios.
There was a problem hiding this comment.
This is a good point. There's a challenge here where you run into the XUnit case.
To get to an actual "idea" of if the package supports a specific framework is layers deep to the dependencies defined such as:
So in these cases, we don't have a good answer without iterating dependencies.
There was a problem hiding this comment.
That totally makes sense.
I just thing integrating it differently, not in an additive way might save us some space. Right now there's a lot.
There was a problem hiding this comment.
We just need to consider a tab design for these pages as a "Future Possibility". Dependencies, Frameworks, Version History, Dependents (Used By), etc really belong in their own individual tabs so everything isn't stacked ontop of each other. README for example will make scrolling to get to one of these a default experience.
/cc @jcjiang may be worth adding to this section!
There was a problem hiding this comment.
Discussed offline and we'll consider these to be universally compatible at this stage. I've added - A design for meta packages to future possibilities, and splitting expanders out to tabs may be called out here or in anothr spec. Up to you, @jcjiang. As we've nailed down the pertinent corner cases, for now perhaps we can merge this?
|
Have discussed with @jcjiang (and mined from stats) offline, and regarding the outstanding unanswered question (on-screen format), we've elected to go with a flat list per original spec. The figures don't support the need for anything more complex at this stage (details of TFM numbers pushed to spec). So, awaiting approval to merge. FYI @jcjiang. |
| - Only 445 have more than 5 supported TFMs | ||
| - Only 16 have more than 10 | ||
| - Only 1 more than 15 (and it has 16) | ||
| So, we'll go with a flat list for now and look at other options for subsequent work if desired. |
There was a problem hiding this comment.
I can also work with folks on the UX side, accessibility of information here is more of a PM/UX question so happy to chase that down
drewgillies
force-pushed
the
dev-drewgil-add-nuget.org-tfms-spec
branch
from
8f5e2d6 to
6196982
Compare
|
@joelverhagen @JonDouglas @skofman1 @jcjiang Note the stats in the Q&A on the spec now. Only 16 in 100,000 package/versions had more than 10 TFMs. Fewer than 1% had more than 5. So putting color-coded tiles across the top like this would be tenable, visually appealing and not hog real estate. The color-coding makes for easy focusing in on relevant TFMs. The sacrifice in this approach would be click data for determining success. But my 2c is that we may be compromising customer joy to achieve this even with the old display approach, and it may not be a good trade. Thoughts? |
|
The original proposal was both. The frameworks node as is and a banner next to the package ID showing the platforms supported like pub.dev & npm. I feel like this is a future opportunity and can be done after this implementation? I can provide some screenshots and mock-ups when I'm at a computer next. |
|
Note: They would show platforms supported by the TFMs, not the frameworks themselves. We wanted to abstract people knowing what a tfm meant in terms of platforms. |
That would definitely need further exploration then, as in a pre-.NET5 world we don't have ready access to that information. For example, what would we put in this list for platforms when all we have is the TFM What are thoughts on using a tiles approach for supported TFMs like we see in FuGet (above)? It sounds like you're leaning away from that idea. |
|
I've done a bit of discovery here already. It comes down to portable and platform assets. For netstandard, it's a portable asset that can be used everywhere, in previous mock-ups that's known as simply supporting ".NET". For platform specific assets, you would then see the platform name associated. I.e Windows, macOS, Android, iOS, etc. This mostly gets difficult in terms of multiple TFMs that support a single platform with different frameworks, but it would have the fallback of the frameworks node to know exactly what. |
|
Here are some mockups to help portray this idea:
Some other ecosystem examples:
I feel strongly that giving users a list of all the TFMs across a screen is unproductive. It's great if nothing else exists, but that's why there's a fallback section for those who want to see exact long names & versions supported. Users barely know what TFMs are today let alone should they need to use a decoder table to understand if they can install and use it to target a platform. This story gets much better post .NET 5 with |
|
I would propose that we keep this spec within the scope of just showing the frameworks node as is & we continue the discussion of "portable/platform asset badges" in a separate proposal as it largely has more to do with filtering & compatibility. |
|
Agreed with Jon that we should keep the spec within scope of the frameworks node. Platform asset badges will come with a lot of additional technical decisions to make so let's continue that discussion separately. |
|
@JonDouglas , @jcjiang , agree that this spec should remain within scope of the frameworks node. However, my concern is that if we ship only this node, and not have tags as well, customers will perceive this as underwhelming. |
|
What do you all feel about surfacing tags for .NET5/6 compat and not for all? |
|
@anangaur , isn't the "big question" when it comes to compat is .NET Framework vs. Core? |
|
May be that. I was hinting at doing a thin slice if possible for things that matter. Could be .NET5/6 compat or .NET Core vs. Framework, based on what's needed. |
|
Agree that for tags it should be a thin list with the most important compat. The "Frameworks node" can be more detailed. |
|
Okay, it looks like we've come in to land on this:
I've put this in the spec under Minimal Requirements:
As we're now talking variants, I'm going to merge this as a |
|
New PR is here: #10605. I believe I have everyone on it as reviewers who's contributed here. |
Quick link for viewing the spec: https://github.com/NuGet/Home/blob/dev-drewgil-add-nuget.org-tfms-spec/proposed/2021/NuGet.orgTFMs.md
Addresses the Nuget.org UX portion of: NuGet/NuGetGallery#8387
In brief, we want to list TFMs on the Package Details page, and to arrive at consensus on how best to do that. My 2c: let's put this expander at the top above Dependencies, and show a flat list of friendly names in lexicographical order. Let's discuss! :)