Bevy Assets Cards Layout Update

[BlackPhlox]

(WIP)

Part of #159's tracking issues :

• Prettier small cards in list view
• Assets can have one primary tag and several secondary tags, can filter on tag

Requires metadata specified in #230

A page view per asset prototype referenced in #159 from discord by giusdp

Design prototypes of the small cards in bevy-assets list view:

[ickk]

With the help & input from @alterae, @BlackPhlox, @cart, @DJMcNab, @mockersf, @neo97x, @TheRawMeatball, @Weasy666, we iterated on this design for asset cards: https://jsfiddle.net/tqnr5a6v/

I think the big useful feature that is still missing is a download counter.

Would love to hear thoughts on this.

[cart]

I'm a big fan! If we're going to use "license and label color coding", I think we should formalize the categories:

• Blue: ideal / up to date / free and compatible with bevy / no need to think hard about the details of depending on it
• Orange: not up to date / warning / might need to think about the details of consuming it (proprietary, license terms that might affect your ability to write code / publish a game).
• Gray: neutral, not risky, but also not "blessed"?

We might also want to extend the "blue" color to other "permissive" licenses, such as "standalone MIT" and "zlib".

[DJMcNab]

I think if we're making 'warning' judgements on licenses (which to be clear, I think we probably should), then I think we would probably do well to have a ⚠ icon next to them with a tooltip. That is, something clearer than orange highlighting, which is another kind of highlighting, and could therefore be misinterpreted as positive (and is potentially colourblind unfriendly).

Edit: It's been pointed out that this message doesn't make it super explicit that I'm saying to remove the orange highlighting entirely

My suggestion for a way to do the 'larger set' of highlighted blue ones was anything which would be accepted by bevy's deny.toml (ideally automatically checked based on that and the latest crates.io release; we should also check for licenses changing and require that to be manually reviewed).

I am slightly biased towards only highlighting MIT/Apache as blue makes sense, as a nudge towards it.; but I think doing it for any permissive license makes sense.

[ickk]

I thought about the license thing a bit; I think from both a UX perspective and from a 'what opinion does bevy want to have', and I think just having blue solely for dual mit/apache makes the most sense.

1. Users don't need to think about any additional license complexities at all (if they choose 'the blue one').
2. We very very gently encourage the ecosystem to use the bevy-compatible license combo, (which will help if a plugin were ever to be considered for upstreaming).

[ickk]

~~Additionally, I'm slightly biased against warning for 'bad' licenses. Licenses can be extremely controversial, and I think positive reinforcement for our preference is good, but negative reinforcement can potentially leave a bad impression of bevy on 'GPL enthusiastic users' for instance; endorsement vs contempt.~~

edit: Alright, after further discussion I'm mostly fine with this.

[mockersf]

warning would not be on "good" vs "bad" but on "compatible with Bevy's license" vs "not"

[cart]

I think its important to call out that "Bevy license compatibility" probably isn't what most users need to optimize for when selecting dependencies. Its "ease of compliance when developing and releasing an app / plugin". Apache-2.0, MIT, zlib, and other licenses in that vein all have the potential to require attribution and additional license boilerplate, but give free rein over the code otherwise. So complying requires going through very similar processes and levels of investment.

GPL fundamentally changes how users can interact with the dependency code, so it is "different". Proprietary code also obviously changes the rules in arbitrary ways.

I think "free and easy to comply with" vs "not free / not easy to comply with" is more important to distinguish between than "exact bevy license match" vs "everything else".

[ickk]

In that case we should just have 2 categories: "mit, zlib, Apache, unlicense, et c." and everything else should be warned against since either it's not free enough or we don't know - either way requires extra care.

I was hoping we could make a stronger endorsement of the mit/apache dual license because it will gently push the asset making community to use those licenses. It would mean more assets would be able to share with/between each other - even long after contributors disappear and relicensing becomes impossible.

It's a question of 'what is most helpful to the user selecting an asset' vs 'what do we want to endorse so that we grow the bevy ecosystem in a way that is healthy, flexible, sustainable'.

[IceSentry]

Recently, there's been a lot of people asking about the ability to see the bevy compatible version in the asset card. I would suggest making a PR without the license on the card since everything else seems approved by the community.

We can tackle the license part later, since having the bevy version is more important than what we currently have. Especially with train releases this information becomes really important.

[cart]

I think we can close this out, now that the new cards / metadata are merged.