Shields: Support logo= to turn off the badge

Created on 1 May 2017  路  10Comments  路  Source: badges/shields

From https://github.com/badges/shields/pull/812#issuecomment-298410104:

Please consider not adding the logo on "custom" badges (i.e. ones with labels, etc). Alternatively add logo images for all services (e.g. Travis CI).

frontend

Most helpful comment

Here's a bit of a historical perspective.

I agree with @wopian; accepting having a logo by default for non-social badges was a weakness on my part during the review of certain badges.
I felt bad to accept the patches, and I shouldn't have. I would be OK with the removal of logos by default (except for social badges, where they are part of the tradition).

(By social badges I mean badges that use the social style.)

However, even for social badges, I wanted to have a way to block a default logo. Adding ?logo would do that, and I would welcome a patch that removes a logo that way.

Furthermore, we do have a few logos in /logo/, and currently adding logos to custom badges is harder than it needs to be; it would be welcome to also be able to specify logos by reference, eg. ?logo=twitter.

All 10 comments

I was the one to merge that change, though I'm open to reconsidering it.

The social badges have logos. Apart from those, 98% of badges do not. Only three badges do: Gitter, Bithound, and since yesterday, Appveyor.

Some options we could consider:

  1. Accept PRs to add logos to any badge. Shown by default. Consumer could hide it. (e.g. ?logo=false)
  2. Accept PRs to add logos to any badge. Hidden by default. Consumer could opt in to showing it. (e.g. ?logo=true)
  3. Accept PRs to add logos to any badge. By default, hide the logo when the label has been customized. Show it otherwise. Consumer could override this as well.
  4. Generally declining logo PRs.
  5. Other??

It's reasonable to maintain optimized logos, where they can be obtained, for the services we support, and ship them through shields. That's preferable to everyone encoding logos into their badge URLs, which seems totally unmaintainable. @techtonik I'm aware logos are important to you, and I think you're not alone. I'm certainly happy to accommodate any consumer who wants logos.

Should the logos appear by default though? Simplicity and uniform appearance are hallmarks of the badge design, which a lot of work has gone into.

I'm especially interested in what @espadrine has to say.

Thank you both @techtonik and @paulmelnikow for considering this in such a timely manner. Thank you @paulmelnikow for the comprehensive write up.

  1. Accept PRs to add logos to any badge. By default, hide the logo when the label has been customized. Show it otherwise. Consumer could override this as well.

+1 for this option.

Should the logos appear by default though? Simplicity and uniform appearance are hallmarks of the badge design, which a lot of work has gone into.

If uniform appearance is one of the primary requirements, then it follows that logos should not be included by default, simply because not all badges have logos (i.e. option (2)).

However I think a good compromise is option (3).

Logos shouldn't be on badges by default imo. From the spec:

non-promotional: badges should not advertise but instead provide value through information

How I interpret that is it shouldn't matter what service its built on, just that its passing/failing for a platform. Plus it stands out by quite a bit 馃槩

Edit: Currently the only way to hide it is to set &logoWidth=0.1, which still pushes the text to the right quite a bit due to the logo padding:

@wopian "windows" is not the default badge, so icon there feels a bit awkward, but on Appveyor badge it is logical to have this for a faster scan.

Anyway, I should open an issue to disable the logo first and then let discussion continue on whatever to implement logo hiding be default.

Anyway, this seems logical for me:

  1. provide logo on default service badge (and add docs on how to ad one)
  2. hide logo (with logo=false) if badge is customized
  1. track how many times people hide or enable logo (which will be against shields promise of no tracking)

Very confusing if you have builds for win and linux/osx running...

travis-without-icon

Even if you try to customize them and write the os there, you don't get a uniform look because you can't disable appveyor logo then.

What you normally want is either:

  • have no logos (not great if you use several like travis+appveyor to cover all major os)
  • have logos of all your build services
  • either of the above + customized titles

    Any mix is weird here



Please add ability to disable logos and support more logos in general (esp. travis used by a lot and here is differentiation needed, maybe same problem for jenkins etc.)

+1 for option 2.

Here's a bit of a historical perspective.

I agree with @wopian; accepting having a logo by default for non-social badges was a weakness on my part during the review of certain badges.
I felt bad to accept the patches, and I shouldn't have. I would be OK with the removal of logos by default (except for social badges, where they are part of the tradition).

(By social badges I mean badges that use the social style.)

However, even for social badges, I wanted to have a way to block a default logo. Adding ?logo would do that, and I would welcome a patch that removes a logo that way.

Furthermore, we do have a few logos in /logo/, and currently adding logos to custom badges is harder than it needs to be; it would be welcome to also be able to specify logos by reference, eg. ?logo=twitter.

I opened #1092 which includes support for logos by reference a.k.a. named logos, while turning off logos by default, except for social badges, which can also be turned off if desired.

@paulmelnikow does that mean that logo= turns off the logo?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

calebcartwright picture calebcartwright  路  3Comments

paulmelnikow picture paulmelnikow  路  3Comments

rominf picture rominf  路  3Comments

Fazendaaa picture Fazendaaa  路  3Comments

AlexWayfer picture AlexWayfer  路  3Comments