search

umbraco / Umbraco.Marketplace.Issues

Public issue tracker for Umbraco Marketplace
2 stars 0 forks source link

Enhancement Suggestion: Group Related Packages #60

Closed TRexStark closed 1 year ago

TRexStark commented 1 year ago

As the subject states, in some cases you find packages that relate to the same - let's call it 'context' from the same developer - even from HQ, and when there is a large number of them, it just makes the Marketplace seem cluttered.

For example; there is all these Umbraco Commerce Payment Providers listed individually, then, UmbCheckout different parts (Sorry Aaron, if you see this - nothing against you), and few others I've seen before.

Maybe there could be a feature allowing developers to group related packages under a "Package Group", then when you click on this Package Group, you can see the multiple separate packages under the same umbrella.

This will make the Marketplace more organised, less cluttered and easier to navigate.

leekelleher commented 1 year ago

The Marketplace documentation does ask that "only the installable component of your package" be tagged with umbraco-marketplace (on NuGet). ref: https://docs.umbraco.com/umbraco-dxp/marketplace/listing-your-package#requirements

So it's more that the package developer has tagged the child/add-on packages/libraries incorrectly, and they appear on the marketplace listing.

AndyButland commented 1 year ago

We do actually have a feature to support this, although it's slightly different to the point @leekelleher makes above.

The Marketplace documentation does ask that "only the installable component of your package" be tagged with umbraco-marketplace (on NuGet).

This is really to avoid the listing of "core" packages - so for example we have Umbraco.Forms and Umbraco.Forms.Core. Developers install the former, and we don't want or need the latter on the Marketplace at all - so we ask developers to not tag those, so we don't pull them in.

@TRexStark is more talking about - I think - those packages that you would want to install, but are more "add-ons" to a main package (rather than "core libraries").

For that we have the ability to flag a package as being a "sub-package" of another one. It's documented here - see the details of IsSubPackageOf - and was introduced in this blog post. If set the package won't appear in the search results, but does appear as a type of "related package" on the main package's details page itself.

So technically we support it already... but it is up to the package developer to opt into it. There are some cases where it would perhaps be better that they chose to, but we aren't at the moment moderating and enforcing it.

Lastly - and swapping hats a moment to an "Umbraco marketing" one! - we decided to list the Commerce add-ons individually just as they do reference some valuable brands that it's good that we show we have some support for. E.g. if someone comes to the Marketplace and searches for "Stripe", it's nice they get an upfront result in the results. So that was the thinking behind that choice.

TRexStark commented 1 year ago

Thanks @AndyButland and @leekelleher. Both responses are valid and andy's explanation is more what I was referring to. But maybe even Sub-Packages could be searchable and then the main package description can list them in the main view. But if this is left as a choice, then it is what it is. Closing this for now.