Delegate logos to simple-icons

[paulmelnikow]

As discussed at #2463 (comment):

I think we should try to defer all icons to simple-icons.

I agree, I don't see a real advantage to keeping our own collection of icons.

Tasks:

• Modify our logo guidelines to say we are no longer accepting new logos
• Match up our existing logo collection with simple-icons, and get our existing logos matched in there. Maybe in the process, one of us could ask to join as a co-maintainer.
• Remove our existing logos, leaving aliases in place for if needed for backward compatibility.

[chris48s]

I've had a quick pass over our logos dir. These ones are already in simpleicons:

• bitcoin.svg
• circleci.svg
• discord.svg
• docker.svg
• github.svg
• gitlab.svg
• gitter-white.svg
• npm.svg
• paypal.svg
• serverfault.svg
• slack.svg
• stackexchange.svg
• stackoverflow.svg
• superuser.svg
• telegram.svg
• travis.svg
• twitter.svg
• windows.svg

The simpleicons version isn't the exact same logo in all cases, but I'm in favour of just standardizing on the simpleicons version.

These ones don't exist in simpleicons:

• appveyor.svg
• azuredevops.svg
• codeship.svg
• dependabot.svg
• eclipse.svg
• lgtm.svg
• liberapay.svg
• matrix.svg
• postgresql.svg
• scrutinizer.svg
• sourcegraph.svg
• tfs.svg

I'm not sure if every single one of these will definitely meet all of their guidelines, but its worth a bash submitting some PRs and seeing where we get to.

We do also carry a couple of logos relating to deprecated services:

• bithound.svg https://github.com/badges/shields/blob/master/services/bithound/bithound.service.js
• gratipay.svg https://github.com/badges/shields/blob/master/services/gratipay/gratipay.service.js

which we should take the opportunity to remove.

[RedSparr0w]

Thanks for that list @chris48s,
I've done a quick mock up showing the differences between each of the logos:

Icon	Shields	Simple-Icons
bitcoin
circleci
discord
docker
github
gitlab
gitter-white
npm
paypal
serverfault
slack
stackexchange
stackoverflow
superuser
telegram
travis
twitter
windows

[paulmelnikow]

Thanks for putting those together!

It's a bit of a mixed bag, isn't it?

Looks better multicolor

Icon	Shields	Simple-Icons
bitcoin
gitlab
npm
paypal
stackexchange

Looks better in simple-icons

Icon	Shields	Simple-Icons
docker
github
twitter
slack
stackoverflow
windows

Shields color looks better

Icon	Shields	Simple-Icons
circleci
discord

Other

Icon	Shields	Simple-Icons	Note
gitter-white			simple-icons color conflicts with shields name
serverfault			don't love either of these
superuser			simple-icons scale is better though I kind of like our two-color version
telegram			our color looks bad on dark
travis			don't love either of these

[chris48s]

Good work on those comparisons @RedSparr0w - that's really useful.

It's a bit of a mixed bag, isn't it?

Agreed. Having seen them all laid out next to each other I'm going to row back slightly on my "I'm in favour of just standardizing on the simpleicons version" comment. There are a few where the one we're using is a better choice in the situation where its going to be displayed really small. Equally, the number where ours is 'better' (read: more optimised for our use-case) vs the number where the one in SimpleIcons is is 'better' is about the same.

I suppose it depends a bit on the tradeoff:

What do we gain from having a slightly more optimised logo for 5 or 10 services (accepting that one of those - npm - is one of the most heavily used).

VS

What do we gain from not having to maintain/review our own icons or any of the code around using them.

As another data point to consider, I started having a go at contributing some of the icons we use to SimpleIcons. Their guidance for icon submission is more stringent than ours (not necessarily a bad thing), so there is some work involved to meet their requirements.

Refs

• add Appveyor icon simple-icons/simple-icons#1128
• Request: PostgreSQL Icon simple-icons/simple-icons#1129

[ericcornelissen]

Hi everyone 👋 I'm a maintainer over at SimpleIcons and noticed some PRs/issues referencing this issue. First of all, I'm glad to hear you folks are considering using the icons we provide! I'm not all to familiar with this project but I'm willing to learn and help you guys with integrating SimpleIcons 😃

First of, let me say that I think it is possible to make icons available for your usage even if they do not necessarily meet our strictest requirements (which currently is based on Alexa rankings), but to be honest I don't expect any issues at all in this regard.

I think that the color of the icons is going to be the biggest issue. We try to specify the main brand color, rather then a color that looks good on a shield. My first suggestion here - although I have no clue if its feasible - is to allow your users to just use a white version of the icon if they wish to.

As for the multicolored icons, we have a related issue on that topic (simple-icons/simple-icons#1060), but I don't see it happening anytime soon...

One last note, looking at @paulmelnikow I see for example that the Travis CI icon doesn't look very good on badges. Unless Travis CI has guidelines restricting us to change the icon, I'm totally fine with updating the Travis CI icon (and the same goes for other icons of course). Relatedly, if a brand has guidelines that say you should use a specific version of the logo, arguably you should use that even if it doesn't look as good on a badge 🤔

[RedSparr0w]

Thanks for chiming in @ericcornelissen 😄

First of all, I'm glad to hear you folks are considering using the icons we provide! I'm not all to familiar with this project but I'm willing to learn and help you guys with integrating SimpleIcons 😃

We are currently already using simple-icons for our badges where we do not already have an icon of our own, Glad to see simple-icons using our badges on the readme 👍

I think that the color of the icons is going to be the biggest issue. We try to specify the main brand color, rather then a color that looks good on a shield. My first suggestion here - although I have no clue if its feasible - is to allow your users to just use a white version of the icon if they wish to.

Currently we by default use the brand color when a user doesn't specify the icon color:
https://img.shields.io/badge/Nintendo-Switch-E60012.svg?logo=nintendo-switch

Or the user can specify any specific color using ?logoColor=whitesmoke
support rgb(a), hsl(a), hex(FF0000), css color names
https://img.shields.io/badge/Nintendo-Switch-E60012.svg?logo=nintendo-switch&logoColor=whitesmoke

Unless Travis CI has guidelines restricting us to change the icon, I'm totally fine with updating the Travis CI icon (and the same goes for other icons of course). Relatedly, if a brand has guidelines that say you should use a specific version of the logo, arguably you should use that even if it doesn't look as good on a badge 🤔

We try to consult any documentation we could find before merging logos to make sure we followed the brand guidelines, although some may have changed since the design was implemented.

Having seen them all laid out next to each other I'm going to row back slightly on my "I'm in favour of just standardizing on the simpleicons version" comment. There are a few where the one we're using is a better choice in the situation where its going to be displayed really small. Equally, the number where ours is 'better' (read: more optimised for our use-case) vs the number where the one in SimpleIcons is is 'better' is about the same.

I don't think we need to move all our icons over to simple icons (specifically the multi color ones which don't look as good monochrome), but any that already look very similar should probably be moved over.

We also should still accept the odd logo which wont fit simple-icons guidelines.

[ericcornelissen]

Thanks for the clarification @RedSparr0w 👍

Currently we by default use the brand color when a user doesn't specify the icon color

In that case my advice would be to by default use a color that is legible on the badge and add a color keyword like "brandColor" that will pull the brand color from SimpleIcons. But I guess that decision is up to the maintainers.

We try to consult any documentation we could find before merging logos to make sure we followed the brand guidelines, although some may have changed since the design was implemented.

Makes sense, just wanted to point out that our versions are also not set in stone 🙂

[chris48s]

I've been on a bit of a voyage of discovery attempting to upstream some of our logos to simple-icons:

https://github.com/simple-icons/simple-icons/issues?q=author%3Achris48s

and I have learned several interesting things from going through this process and getting my PRs reviewed by the Simple-Icons team :) Some of these were expected and some of them weren't:

• Editing some of our icons to match the Simple-Icons guidance has made me realise that there are some of our icons which have issues that could be improved (e.g: they can be further minified without losing any detail, they aren't properly centered or scaled, etc)
• Editing some of the icons did require some work and a bit of learning on my part
• Not all icons reduce to a strictly 2-colour format without losing detail
• Sometimes the logo version that is preferred by Simple-Icons isn't the one which is most appropriate for use on a badge (this is not a criticism - its just a reflection of the fact that our projects have different goals)
• Sometimes the default colour that is preferred by Simple-Icons isn't our preferred colour/the most appropriate for use on a badge (same caveat applies)
• We don't really know where all of our icons came from because we don't require our contributors to specify a source

There are a few things where I've got concrete actions to take next based on that:

• There are still five icons which I haven't attempted to submit upstream. I think its probably useful to submit the remaining five.
• We do want to maintain our own version of some small subset of logos for one reason or another
• Having upstreamed the logos, I now need to make some pull requests to retire some of our icons in favour of the Simple-Icons version (which I've not done yet)
• There are some icons where we want to retain a custom version which is different to the Simple-Icons version but I now want to submit a PR improving ours in some way

There are also some areas where I've got questions or I'm unsure where we want to go next:

• What is a senisble thing to do in the case where Simple-Icons host a useful icon, but the only difference is its not in our preferred colour by default:
  • Do we want to keep our own icon in these cases?
  • Is it useful to be able to set our own default colour on it?
  • Is this just making life more complicated for ourselves?
  • Is it best to leave the user to deal with it using the ?logoColor param?
  • Is it best to think about this under Automatically show light or dark logos depending on left color #2431 ?
• Do we want to request logo contributors to submit logos to Simple-Icons (first) instead of directly to us?
• Accepting that we're going to maintain some logos in our own project (but as few as possible), there are a number of ways we might improve our own logo submission guidelines which could bring benefits (e.g: smaller file sizes, more consistently formatted icons, etc). For example, we might adopt some of these requirements: https://github.com/simple-icons/simple-icons/blob/develop/CONTRIBUTING.md#5-check-the-icon but this may also add some extra work for contributors and review overhead for us. I'm slightly unsure what qualities we want to try and optimise for here. :think:

Finally, one interesting thing that Simple-Icons do is they have some guidance of how popular a brand has to be before they'll accept an icon for it (see discussion: simple-icons/simple-icons#1139 (comment) ). I wonder if we could learn from this and establish some benchmark of how popular a service should be before we're willing to take on maintenance of a badge for it. Does anyone else think that might be a beneficial idea to steal?

[chris48s]

Update: simple-icons v1.9.18 now also includes a version of all our custom logos except for LGTM, which is still under review. Here's a table comparing the new icons:

Shields	Simple Icons (default)	Simple Icons (white)

There are a few cases where there is a naming difference. e.g: scrutinizer in our logos, scrutinizer-ci in simple-icons, eclipse in our logos, eclipse-ide in simple-icons but we can always alias those for legacy compatibility.

As we've already identified there are a lot of cases where simple-icons holds a good icon, but the default colour doesn't look good on a dark background (in many cases, our icon is basically identical apart from the default colour). It seems excessive to maintain our own icon in these situations. I think I'm becoming more convinced the ideal solution to this is #2431

btw, fair play for assembling that first table @RedSparr0w - having just gone through the process of generating each of those images, saving them off, uploading them and making a markdown table, I know exactly how laborious the process is!

[RedSparr0w]

Wow, Nice work getting all those logos merged!

It seems excessive to maintain our own icon in these situations. I think I'm becoming more convinced the ideal solution to this is #2431

I will look into implementing #2431 soon, once i get back into the flow of things 😄

btw, fair play for assembling that first table @RedSparr0w - having just gone through the process of generating each of those images, saving them off, uploading them and making a markdown table, I know exactly how laborious the process is!

Haha yeah, i thought about trying to automate it a bit, but figured it would just be quicker & easier to just manually do it all.

[chris48s]

Most of our icons are deleted in #2857

#2872 #2873 and #2874 are open proposing some further edits to some of the multi-coloured ones we're keeping.

There are 4 outstanding..

• LGTM: currently ignoring this one as simple-icons 1.9.19 will have an icon for this. We can probably drop it when we upgrade.
• Telegram: We've kept our icon, but the default is black on dark background. I think I want to see if I can improve this. Maybe this version https://commons.wikimedia.org/wiki/File:Telegram_logo.svg would work?
• Travis, Serverfault: Don't know what to do with these. Our version isn't great, neither is simple-icons. They're just a bit too fiddly/detailed to work well that this size really :/

I also want to review the logo submission guidelines before we close this off

[paulmelnikow]

• Maybe this version https://commons.wikimedia.org/wiki/File:Telegram_logo.svg would work?

That looks nice. Are you thinking it would be white on a blue circle for both the light and dark badges (sort of like Bitcoin)?

[chris48s]

Had a go at this. This version has a lot more contrast, but it loses quite a lot of detail at small size:

• 
• 

not sure if that is better..

[paulmelnikow]

It looks good on Retina!

I guess you could try darkening the gray along the “fuselage” to preserve contrast at small sizes.

[chris48s]

Once simple-icons 1.9.19 is available, I'll do another PR to remove the LGTM logo in favour of the SI version. Beyond that, I think everything under this banner is done or there's a PR open for it so I'm going to close this off. If anything else is still outstanding, feel free to re-open

[cactysman]

I'm glad this topic is being discussed!
Just today I stumbled across a few icons that did ignore the logoColor parameter, but then I realized that those are the ones that overlay the simple-icons ones.

[paulmelnikow]

Ah, that probably should be included in the documentation for logoColor.

[Borda]

Hi, do you have an example of how to use simple-icons and is there an indication of which version is used?

[chris48s]

@Borda Logos can be included with the logo param e.g: https://img.shields.io/npm/v/npm.svg?logo=javascript
We're currently using 4.25. There's a PR open to deal with the non backwards-compatible changes in v5
See #5369 for more info on upgrade schedule