Offer alternative to similar tools

[Dmitry Iv.]

Many tools have alternatives or closely related projects.

Eg. for viewing npm files there are at least 3 alternatives:

• npmview
• npmfs/package-name
• unpkg.com/package-name/
• runpkg.com/?package-name

Would be helpful to have them consolidated or mentioned, wouldn't it?

[Stefan Judis]

I like that idea. What would you have in mind? How would you approach that?

[Dmitry Iv.]

Just to start thinking - there's example from bundlephobia ticket pastelsky/bundlephobia#179
.
Maybe a small icon with popup with a list of alternatives would work for the beginning?

[Stefan Judis]

Thanks for giving more input! I think that's a great idea and from UI perspective I'm sure we could figure something out. What's not really clear to me is how we would model that from a data perspective.

Currently, adding a new helper is fairly straightforward. How would we build the connections between the helpers? I don't think that we could expect a person adding a helper going over all the tools and figuring out what belongs together. The tagging approach is the closest I came to a maintainable solution. Looking for ideas there, too. 🙈

[Dmitry Iv.]

Alternative tags is actually good idea. Eg. tag ‘alt:npmview’ would allow grouping all npm viewers.

…

On Wed, Jul 15, 2020 at 1:50 AM Stefan Judis ***@***.***> wrote: Thanks for giving more input! I think that's a great idea and from UI perspective I'm sure we could figure something out. What's not really clear to me is how we would model that from a data perspective. Currently, adding a new helper is fairly straightforward. How would we build the connections between the helpers? I don't think that we could expect a person adding a helper going over all the tools and figuring out what belongs together. The tagging approach is the closest I came to a maintainable solution. Looking for ideas there, too. 🙈 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#294 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACJII7S2ODGUL253JPCWODR3U7QZANCNFSM4OZYNYJA> .

[Stefan Judis]

Thanks @dy. I'm not sure if i like the idea of introducing a 2nd level.

But I'm not sure how another tag would help with the problem of maintenance and keeping/building all these connections? It would still mean that someone has to go through all the helpers to figure out if there is a similar one already or?

[Dmitry Iv.]

Well, the baseline is - there is a set of alternatives, so that set needs to be managed anyways.
The relation of item - set is many to many, therefore there needs to be an intermediate table/dict, and tags is one of possible forms of it, already existing.
That's all theory of course.

[Stefan Judis]

Well, the baseline is - there is a set of alternatives, so that set needs to be managed anyways.

I understand and I believe that could have a lot of value.

that set needs to be managed anyways

And that's where I don't see a way to make that possible without a massive time investment. Unfortunately, I can't commit to doing that and we can't expect people to scan 250+ tools when adding a new helper. :)

That's why I'd consider this idea out of scope. :/

[Dmitry Iv.]

I don't see why there should be a massive initial time investment, that can be gradual, I see no value in that spend. I think the value is mostly in keeping track of alternatives if they become known, rather than running full-blown service. Maybe even having a per-tool short list of alternatives would be enough and possibly allow to reduce duplicates.
I used to keep track packages alternatives.
Regardless, feel free to close then.

[Stefan Judis]

Alright. Thanks again for the suggestion, I'm closing this because of the mentioned reasons. :)