Flatten Badges #185
Comments
|
Done #159 |
|
No, I meant for the SPECIFICATION.md and all the default badges. |
|
/cc @olivierlacan |
|
Ping @olivierlacan @espadrine |
|
Would you agree that whatever is spec'ed should appear with the By the way, I am no designer. |
|
I was thinking flat but still rounded edges: |
|
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? |
|
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? |
|
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. |
|
@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 |
|
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" [email protected] wrote:
|
|
@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:
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 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. |
|
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 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 The first commit for
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. |
|
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?
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. Example: 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: 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.
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. |
Also, allow extending analytics. Related to issue #185.
|
Came across the
I had two reactions:
Basically I'd like 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. |
|
👎 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. |
|
i dont like the Path: or with keyword: Subdomain: |
|
@muescha Unfortunately, the |
|
@espadrine when is the |
|
@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.
Each date includes 30 days of shields.io usage leading to it. Figures are lower bounds. 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 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 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!
|
|
Got your tweet, @espadrine. Gratipay links out to |
|
@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. |
|
Feb 1 is approaching. It would be nice to get some confirmation if that date is still "tentative". |
|
@mgedmin Barring unforeseeable events, it will be done at the planned date. |
|
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". |
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)
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
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.
The text was updated successfully, but these errors were encountered: