Flatten Badges #185

caffinatedmonkey opened this Issue May 22, 2014 · 53 comments


None yet

In the past few weeks github has been flattening its design by removing gradients and drop shadows across the board. The badges don't fit into github's design as well as they used to 😢

Something like this:


Instead of:


This also shaves 100B off the request.

KenanY commented May 22, 2014

Done #159


No, I meant for the SPECIFICATION.md and all the default badges.


Would you agree that whatever is spec'ed should appear with the style=flat option?

By the way, I am no designer.


I was thinking flat but still rounded edges: flat GitHub still has its curves.


I agree, but I don't trust myself as a designer. Not yet, anyway. Do you think you can get a few people to look at it and vote on it publicly here?



What is your opinion on this matter?

mdo commented Jun 2, 2014

I'd love the flatter styles.

Is there anything in particular you want feedback on about the flat ones included here?


Do you have any ideas for improvement?

mdo commented Jun 2, 2014

The padding is uneven on the top and bottom, and the font family always felt a little awkward. I'd run with some Helvetica and even out that padding if at all possible.


The problem with Helvetica is that everyone doesn't have a Mac. It probably a good idea to use a more open font like Open Sans. Thanks for the suggestions. I'll make the changes.

mdo commented Jun 2, 2014

@caffinatedmonkey True. Could go the Arial route, too. We have a font stack on GitHub that goes from Helvetica to Arial (and after some Linux font) to sans-serif. I know these are images, so whatever you decide is totally fine. I was looking at it merely from a context point of view—that being on GitHub.


What is your font stack and where do you store your web fonts? Since the primary use case for this is in GitHub readmes it would be great if the fonts could share the same cache.

On Jun 2, 2014 7:27 PM, "Mark Otto" notifications@github.com wrote:

@caffinatedmonkey https://github.com/caffinatedmonkey True. Could go
the Arial route, too. We have a font stack on GitHub that goes from
Helvetica to Arial (and after some Linux font) to sans-serif. I know
these are images, so whatever you decide is totally fine. I was looking at
it merely from a context point of view—that being on GitHub.

Reply to this email directly or view it on GitHub
#185 (comment).


@mdo Though the text is aligned it looks unaligned because of the ascenders and descenders. I'm not sure how to fix that. Do you know how?

Here are the images with the font changes:

  • DejaVu Sans, Verdana, Geneva, sans-serif
  • Helvetica Neue, Helvetica, Arial, sans-serif
  • Open Sans, sans-serif (webfont)

In my opinion, Open Sans looks the best but that may be because I am on a Ubuntu machine. One problem I have noticed with loading a remote open sans font is even though it is cached, there is a flash of unstyled content every time.

Here is an image of how everything looks on my Ubuntu machine:


I don't have Helvetica installed. Which one do you want to go with @espadrine? Make sure you consider other platforms in your decision.


I feel that the choice of font should be the same in both flat and traditional designs. In that case, it is a different issue: #97

Also, here's the work that was done to pick the current font list: badges/gh-badges#14 (comment)

I'd love to have a similarly exhaustive comparison if we were to use a different font stack.

There is another possibility which, assuming we use an open font, I can try to perform, although it requires muscle. It requires converting a font to SVG and programmatically add the SVG paths in the badges. It is exactly as hard as it sounds, for each font we do this with, so I personally can't test all those fonts, but I can explain the process, if I end up being successful. Is that work you would be interested in me completing?


I don't think I stated my intent clearly. I would like all the badges to be change to a new flat style which we are discussing here. The gradient design was an old design trend. I think we should phase out theses old designs and replace them with a new flat design.

I'll work on a list and post it here when it is complete.

I'm sure it can't be that hard to convert the fonts to paths on the fly. Inkscape does this. I'll try to find the appropriate source code.

mdo commented Jun 3, 2014

I don't know much about building SVG graphics like this to work cross platform, so I can't be of much help here. I can point out slight tweaks to make like the spacing and font choice, but beyond that I'm useless 😆.

I do like the Open Sans one, too, fwiw.


I would like all the badges to be change to a new flat style

I mostly agree with you. I made the badge by copying the design used before, but I was hopeful for a change some day. Currently, I feel that this should first occur on ?style=flat (which already has quite a few users), see how people react, and eventually make it the default at a future date. Forcing a new design onto every current user without a test run or a poll is a tad too aggressive for my taste. (Yes, I also feel strongly about having a good poll.)

The first commit for ?style=flat was very raw on the design side. I basically looked at @maxogden's design and said "fine". However, I was hopeful that someone would eventually improve it, if not myself.

I'm sure it can't be that hard to convert the fonts to paths on the fly. Inkscape does this.

Converting the fonts to SVG isn't the hard part. Programming something robust and fast that is flexible enough to accept anything from the resulting blob of data is. It is made harder by the fact that I don't really know the technical definition of ascent and descent well enough to implement it. I tried to convert Open Sans to a JSON representation, but the conversion was painful and the result not quite satisfactory. Have a go if this is your cup of tea! I'm trying on my side, we can compare notes. Currently, the idea is to check for the existence of a path from a character in the JSON, then convert that character to an HTML entity and try again if it fails. The fallback returns an empty string.


Looks like I screwed up kerning information, as well. :/


FWIW, most of our border radii are 3px at GitHub. Not that you need to match that – just throwing it out there since these look a bit more rounded.

Also, I ❤️ the flatter look.


Whoa, lots to catch up on. I'm beginning to feel like the only way we'll get people on board with the Shields API is by drastically updating the default look & feel.

I agree with @jasonlong that the radius is to steep on those examples @caffinatedmonkey showed.

@mdo There's a reason I didn't use Helvetica or a similar font-family with the original badges, they're terrible a small sizes. I think @caffinatedmonkey demonstrated that quite well. I don't think there's any reason to change the font family we currently have unless we can find something obviously more legible.

Sorry I took a while on this. I believe you folks are right on the main points, I don't think my quibbles on the minor points matter at this stage.

@espadrine Do you have precise usage stats for the current flat style? I'm just curious. 😃

@mdo & @jasonlong, since you're here. I'm really curious what opinion people at GitHub have of these badges. I've exposed the reasoning behind them at length in SPECIFICATION.md and more recently in a blost post. More pointedly I wonder if people are worried about them being more noise than signal.

I feel like that will always be a struggle (avoiding noise). Making the badges a little less conspicuous aesthetically will probably help a bit. Although I sort of expect you folks (GitHub) to eventually incorporate some sort of equivalent project metadata functionality that will replace and integrate them better.

@caffinatedmonkey Thanks so much for pushing on this issue. 👍

PS: I'll take a moment to utterly disagree on the motivation of changing the design of Shields badges because "gradients are an old design trend". By that logic, flatness will soon be an old design trend too, since it's already been around for quite a while. The only sensible reason to alter our design is to have a positive impact on the end goal of the badges: provide useful metadata about a project. An aesthetic that fits better with the GitHub UI (although that is bound to evolve as well) and stands out a little less from a project README seems to push the goal of this project forward, although ever so slightly. But as I said above, I think the propagation of our API-generated SVG badge has been hindered by the similarity of their design to the original PNG badges. So this change, much like the original change to Shields PNG badges, will probably entice more maintainers to update. I'm all for that.

mdo commented Jun 19, 2014

I don't ever find them noisy save for the super large and elaborate ones for browser testing (not your shields here). These benefit from a darker design to stand out and be easily identified in project readmes.

Alluding to what @jasonlong said earlier, making the badges match some design choices of GitHub could be interesting. I don't know what for sure, aside from matching border radius and font. Maybe our colors for the statuses?

PS: I'll take a moment to utterly disagree on the motivation of changing the design of Shields badges because "gradients are an old design trend". By that logic, flatness will soon be an old design trend too, since it's already been around for quite a while

Hah, hear that. Follow your heart :).


I don't know that I've heard much internally about the badges. I've certainly never heard anything negative. And I've never heard of anyone here looking to build our own badges.

Nobody asked for my 2¢, but I think keeping a very subtle gradient would work nicely. IMO, Google has found a nice almost-but-not-quite-flat aesthetic.

screen shot 2014-06-19 at 2 46 45 pm

I think something subtle like that would look classy. I'd also get rid of the highlight and shadow part of the gradient along the top and bottom edges. The top highlight especially makes the badge look blurry.


Just screwing around in Web Inspector:
screen shot 2014-06-19 at 3 10 00 pm

See actual size w/ 3px radius

Again, just my 2¢. Please feel free to ignore any or all of this. 😉


I really appreciate your input @mdo & @jasonlong. With all things SVG I would defer to @espadrine since, as he explained, the implementation can get tricky.

I really like what @jasonlong suggests above. One of the main reasons I still enjoy the subtle radius and gradient just came back to me: clickability. It's sadly easily lost with flatness and while the information on the badge is clearly the focus, it's good to suggest that there's more on click. Since we can't offer any hover/tap reaction.

Keeping the subtle drop shadow also makes sense to me. White text can be hard to read, especially since we can't be certain of what background color will be used on the value side of the badge.

I'm fine with killing the top highlight.


Here's a comparison where I used @jasonlong's take for version 3.

Version Preview
Shields v1 image
Shields v2 image
v3 image

Still looks like there's some padding/alignment consistency issue on the value side but it's pretty decent progress. I'm wondering if it's not an inherent problem since digits are taller than lowercase characters and since we have a one pixel drop shadow below both the key and the value text.

@espadrine espadrine added a commit that referenced this issue Jun 20, 2014
@espadrine espadrine Analytics: count flat badges requests.
Related to issue #185.
@espadrine espadrine added a commit that referenced this issue Jun 21, 2014
@espadrine espadrine Analytics: count flat badges requests.
Also, allow extending analytics.

Related to issue #185.

Came across the json_spec repo which is using flat badges today.


I had two reactions:

  1. It looks pretty nice, although I think the tweaks we discussed here (border radius most notably) would improve the design
  2. It bums me out that we're offering an alternate design. I understand that it's to satisfy people who like "flat" better, but I'd prefer we stick to offering one single aesthetic (to follow the consistency ideal set forth by this project) and notify the people using this special flat design that we'll send back the official new design whenever we settle on it.

Basically I'd like ?style=flat to return the same badge whenever we have the new flat_ter_ design ready.

What do you think @espadrine?


I agree that having a single design for consistency would be ideal, but I believe we should rely on a smooth transition effort. First, we should get input on the flat design, and perfect it. One day, we'll switch the recommended design to the flat one. Eventually (January 2015 as a tentative date?), we should only send the new design for both styles.

I feel like we should only do the eventual switch after a consensus between badge vendors and relevant participants.

@espadrine espadrine added a commit that referenced this issue Aug 5, 2014
@espadrine espadrine Flat design: use @jasonlong's work.
Part of issue #185.

@jasonlong Thanks for your input! I put it live, and I'm bracing myself for feedback!





@espadrine espadrine added a commit that referenced this issue Aug 5, 2014
@espadrine espadrine Flat design: drop-shadow.
Part of issue #185.

Forgot the drop shadow on the text.

flat-before flat-after flat-shadow


By the way, I feel like, in the end, a third design may be appropriate in some cases:


I believe I can make the shadow change on mouse hover, too.

@mdo, I'm particularly receptive to your feedback on this, seeing as you designed the "fork" button.

I notice some subtle differences with the Twitter button (which I find slightly less appealing because of its in-the-face, excessive gradient) related to both the gradient and the darker bottom edge.

Link to that project for future me: https://github.com/mdo/github-buttons


Looks great @espadrine, nice work!


@espadrine That looks really nice!

lrsjng commented Aug 5, 2014

@espadrine I actually love the real flat and sharp ones better.. is it possible to serve them too? Anyway great work here!


@espadrine the new flat design looks great! Just noticed it on https://github.com/danielgtaylor/jpeg-archive


Thanks for the great feedback!

@lrsjng It is technically possible. However, this change is meant as an improvement over the current flat design, and a plausible replacement for default badges, so I'd like to keep it as ?style=flat. What would you like to name the old one? ?style=deprecated-flat?

(Also, keeping the deprecated version adds a bit of maintainer strain, so if you like the new one enough, I'd be happy not to maintain the old flat design.)

Glaived commented Aug 6, 2014

@espadrine why not ?style=flat-square?

lrsjng commented Aug 6, 2014

@espadrine if it's too much work, just drop it, otherwise style could be called flatter, realflat or tile..



This should have been a new style. Since when does "flat" mean "gradient + drop shadow"?


@shannonmoeller Since Google, apparently: #185 (comment)

@Glaived I like this one. I'll add it back within 24h, and I'll track its adoption.

@espadrine espadrine added a commit that referenced this issue Aug 11, 2014
@espadrine espadrine Support the old flat style as flat-square.
Part of issue #185.
muescha commented Aug 11, 2014

i dont like the ?style= notation
better include it in the path or into the subdomain:


or with keyword:



@muescha Unfortunately, the ?style= notation is not up for discussion. Besides, implementing as a subdomain would make little semantic sense and increase the difficulty of programming and testing for it.


@espadrine when is the flat-square style going to go live? It doesn't seem to be live yet.


@douglaswth Hmm, it should be live by now.


@espadrine Cool, thanks!


I have a tentative date of February 1st in mind for a large switch to the new badge design. The winner is clearly the flat style badge, and it will be made the default.

Date flat flat-square appr. total
dec 6th 27859353 (83.36%) 5562525 (16.64%) 34049073
jan 7th 37223060 (80.98%) 8745309 (19.02%) 38128110
feb 8th 50144198 (78.94%) 13380868 (21.06%) 63525066

Each date includes 30 days of shields.io usage leading to it. Figures are lower bounds.
I'll update it on January, February and March to witness how it evolves. Ping me on Twitter if I forget.

As you can see, it is time to make the change, as the old style represents a minority of usage.

The current default will stay accessible through the ?style=plastic style. The flat-square style will not go away.

I wish to encourage all badge vendors to make the switch at the same time on Sunday 1st (yes, next February has a number of days that is both a multiple of 7 and starts on Sunday). Talking to vendors will happen over Twitter and email. Please note that vendors which currently request the badge from shields.io won't have to do anything and will be served the new style for free. If they choose not to change, they must call ?style=plastic explicitly, which is already possible today.

However, it will be hard for me to talk to every single vendor, so I will list all vendors I talked to here. If I miss one that uses Shields-style badges, please contact them, point them to this comment, and add a comment in this issue with a link to the thread. Thank you all!

whit537 commented Dec 16, 2014

Got your tweet, @espadrine. Gratipay links out to img.shields.io directly with no querystring, so I believe we and our users will pick up the change automatically. Thanks for the heads up! Keep up the great work! :-)


@whit537 Great! I think that will be the story for most vendors, but I ping-ed everyone so that nobody wakes up one morning with their default style switched.


Thanks for the tweet as well. We (@zenodo) hope to have it fixed before your deadline.

mgedmin commented Jan 30, 2015

Feb 1 is approaching. It would be nice to get some confirmation if that date is still "tentative".

@espadrine espadrine referenced this issue Jan 30, 2015

npm library version 2.0.0 #362

2 of 5 tasks complete

@mgedmin Barring unforeseeable events, it will be done at the planned date.

@espadrine espadrine added a commit that closed this issue Feb 1, 2015
@espadrine espadrine Default to flat badges
Closes #185
@espadrine espadrine closed this in f2319a2 Feb 1, 2015
mgedmin commented Feb 2, 2015

The front page still has the following bit:


It would be nice to mention that the "flat" style became default on 2015-02-01 and that the older style is called "plastic".

@espadrine espadrine added a commit that referenced this issue Feb 2, 2015
@espadrine espadrine website: Mention all styles
Part of #185
@mgedmin mgedmin referenced this issue in badges/pypipins Feb 3, 2015

Switch to flat badges by default #34

@espadrine espadrine added a commit to espadrine/coreclr that referenced this issue Feb 8, 2015
@espadrine espadrine Use the new SVG badge style
See http://shields.io for more information.

Full disclosure: I am the maintainer of shields.io and of the SVG badges that came from this project.
The rationale and effort behind switching to the new SVG badge style is detailed here: badges/shields#185 (comment)
@espadrine espadrine referenced this issue in dotnet/coreclr Feb 8, 2015

Use the new SVG badge style #144

@mgedmin mgedmin added a commit to zopefoundation/zope.winbot that referenced this issue Apr 13, 2015
@mgedmin mgedmin Update to flat-style images
Everyone switched on Feb 1, 2015:
badges/shields#185 (comment)

Generated with

    wget -O status_image_success.png http://img.shields.io/badge/winbot-passing-brightgreen.png
    wget -O status_image_failure.png http://img.shields.io/badge/winbot-failing-red.png
    wget -O status_image_exception.png http://img.shields.io/badge/winbot-error-red.png
    wget -O status_image_warnings.png http://img.shields.io/badge/winbot-warnings-yellow.png
    wget -O status_image_skipped.png http://img.shields.io/badge/winbot-skipped-lightgrey.png
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment