Methods to render 'badges' in the Hub

[aaronsteers]

@rwfeather, @cjohnhanson, @pandemicsyn , @edgarrmondragon - What do you think of the various methods of rendering badges on the site.

1. External badges like those from https://shields.io allow us surface near-real-time datapoints, without leaning on ELTP.
2. Custom use of https://shields.io has some limitations on flexible rendering (although perhaps not insurmountable).
3. TailwindCSS can make badge-like rendering of regular text.
4. If combining badges of different types, the eye can catch subtle differences in their rendering.
5. Do we try to make these match each other (for instance via font and color selection), do we just ignore the differences, or do we use a single method so there isn't a difference?

My PR here shows Tailwind and Shields.io next to each other. The "Maintainer" name and "Keywords" are rendered with Tailwind. Others are mostly from Shields.

[WillDaSilva]

@aaronsteers How would it look if we used Tailwind to render a badge that had as associated value? All of the others have a key with a uniform grey background, but then a coloured section to the right for the value.

If combining badges of different types, the eye can catch subtle differences in their rendering. Do we try to make these match each other (for instance via font and color selection), do we just ignore the differences, or do we use a single method so there isn't a difference?

My assumption is that we should be able to use https://shields.io for all of the badges (custom ones included), and use query parameters to adjust the style (e.g. ?style=flat-square). Am I missing something?

[aaronsteers]

Maybe so. Certainly open to keeping things on shields.io. I can give the custom styles a try.

[aaronsteers]

I realized my problem. Some of the dynamic inputs have dashes in the text, which causes "Cannot find badge" if you use the shorthand/default 'dash' notation.

The longer syntax seems safer with dynamic values, and appears to render fine:

• https://img.shields.io/static/v1?label=some-label&message=some-message&color=green

Or if only rendering one text value by sending a blank label:

• Use the color: https://img.shields.io/static/v1?label=&message=some-message&color=green

I wasn't able to switch this and leave message blank - but for a regular rectangle we can just use the above method and use color=grey.

[aaronsteers]

Now rendered all via shields.io, this look is much more consistent. Thanks for your help, @WillDaSilva. 👍

546c4c3

[WillDaSilva]

@aaronsteers Nice improvement! I see that "Stars", "Forks", and "License" are still using the flat-square style, whereas the others are all using the flat style. Is this easy to fix, or can the styles not be changed easily for those ones?

[aaronsteers]

@WillDaSilva - thanks for calling this out. Tbh, I was so focused on the major differences between shield-generated and non-shield-generated badges, I didn't notice the rounded edges vs non-rounded edges.

Since everything is from shields (I think), that should be a quick fix

[rwfeather]

Making our own badges seems feasible, but it's not clear to me what kind of value we might get out of them (other than a chance to add more meltano-branded designs)

If we did there'd be roughly two approaches I think:

• Fetch from the github/gitlab APIs on the client and then render badges client side
• Fetch from the APIs as part of gridsome build and bake them into the static html

The former will get us real time data, but it's unclear to me if we'd take a page load/performance hit. The latter would refresh the data at the same cadence as our current metrics (nightly).

[aaronsteers]

Making our own badges seems feasible, but it's not clear to me what kind of value we might get out of them (other than a chance to add more meltano-branded designs)

Yeah, this makes sense. As I'm learning more about what shields.io can do in regards to custom content, there probably isn't a strong reason to invest in our own rendering as of now.

As per my comment above, the simplest path as of now (until we run into other rendering limitations) is probably to stay with shields.io for the time.