Please provide vector versions of shields about shields HOT 31 CLOSED

Will work on an SVG remake of the badges later tonight and send in a PR.

Will be .svg, as Illustrator can open SVGs, and SVGs being XML will allow more reasonable tracking (at least to a certain degree) than the binary AI files.

from shields.

👍

from shields.

Fixed via #6

from shields.

Just noticed from this preview of upcoming new Shields on Gemfury that they seems to have an improper resize.

There's a rounded corner on the middle of the badge:

@rykov, how did you resize the badge? Can we help you fix it somehow?

from shields.

The badge is automatically resized based on the width of the version string. The rounding is a mistake in our design - rounded rectangles (over free-form paths) are easier to work with within our rendering system.

from shields.

Ok - I've tweaked it to fix the rounding

from shields.

Any way to change your font's rendering in your setup? It's being blurred on the edges (descending part of the g is pretty much blurred out, for example).

Might I also suggest that it be 'gem' as opposed to 'gem version'?

from shields.

@rykov Looks much better, thanks for taking the time to make a tweak. :-)

Like @ackerdev, it feels that the word version is a bit redundant with a version number right next to it. Any reason you wanted to be a bit more verbose?

from shields.

To be consistent with the old version. I think most Gem authors are not aware of this effort, so I think it's better to make changes gradually to keep with the "principle of least surprise". Over time, we'll change it to just gem or rubygem.

from shields.

@ackerdev Those font rendering issues make me think we should eventually take care of the dynamic generation ourselves and simply offer shields-as-a-service ;-)

Let me know if you'd like to start working on something like that.

@rykov Sounds like a good idea, closing this then. :-)

from shields.

Thanks! Did a bit more tweaking for font rendering - take a look

from shields.

@rykov Looking good! 👍

from shields.

Hey @rykov, need any help pushing the new badges live? I'd love to check one more off this list. 😉

from shields.

Been waiting for TravisCI. I will switch it on later today.

from shields.

It's up now, but I'm getting a few queries asking why it's red. I understand that it's the RubyGems.org color scheme, but maybe going with consistency to other badges is better. Especially when we expand to version badges for other languages.

Personally, after seeing a red "gem version" badge surrounded by a bunch of green ones, I would vote for switching to a consistent green.

from shields.

@rykov Just came here to ask about the color as well. I was trying to figure out if something was wrong. I understand Ruby = red, but it really stands out next to other badges:

from shields.

👍 Red color most of the time means "something is going wrong there"

from shields.

@rykov It makes sense that people would be worried about the red, that said semantically there's no reason for the gem version to be green.

It's not up or down, it's just the latest gem version. I care less about consistency than I do about meaning.

I understand if you want to switch to green anyway in the meantime, but I think it would be interesting to explore more neutral colors since no state needs to be conveyed.

On Feb 25, 2013, at 12:51 PM, Michael Rykov [email protected] wrote:

Been waiting for TravisCI. I will switch it on later today.

—
Reply to this email directly or view it on GitHub.

from shields.

@olivierlacan It could be said that green means "nothing is wrong/broken" or "usable condition" rather than "success" in this and other cases. And in the future, there can be further meaning behind the color like "still maintained" or "important security update available"

from shields.

@rykov Green generally does mean "success" or "go ahead". Moreso, the issue here is that "red" relates to "stop" and "something is wrong".

A more neutral color makes more sense here than green.

from shields.

I have a couple comments.

• I think the red is unnecessarily distracting, even though the idea is to represent a rubygem.
• It would be nice and conceivable if badge.fury.io later expanded into other version management frameworks, like npm packages (package.json), jquery plugins (*.jquery.json), etc. A consistent version shield between these kinds of packages could prove to be more appealing across the board.

Suggestions:

1. Use a gray #b5b5b5 color for the version. (same color as the )
   [ gem version | 3.2.0 ]
2. Use the same gray, but shorten up the shield by preceding the version number with a "v"
   [ gem | v3.2.0 ]
[ npm | v0.4.1 ]
[ jquery | v1.0.2 ]
3. Skip the right color side of the shield all together and just go with a small dark gray shield.
   [ v3.2.0 ]

I prefer the last option, but overall, please at least drop the ruby red for a more neutral gray.

If someone with better knowledge of the underlying templates could mock these shield ideas up, that'd be great; otherwise, it'll be a little while before I can get to that myself.

Lastly, I should mention that I think dark gray version-only shield would look great in the title heading of most READMEs. For example, I use a similar twitter-bootstrap label on one of my projects to convey the current version:

from shields.

@rmm5t Great suggestions. I was toying with the idea of grey as well, but I'm worried it might be too dull. That said I agree with all your points except your preferred version. There is semantic meaning to be conveyed by [ gem | v3.2.0 ], you can immediately understand upon discovering the repo that this is a RubyGem or a Node package or a jQuery plugin. This is valuable enough that I wouldn't want to sacrifice it.

Here's a quick render attempt. I preferred a darker grey.

from shields.

@olivierlacan I think that's a great looking improvement. I also now prefer your darker grey after seeing it. I'll concede to your argument for the semantic meaning of the shield version prefixes.

👍 I'd love to see these darker grey versions 🍻

from shields.

I prefer the format [ gem | 3.2.0 ] because it still conveys the full meaning while keeping the version number pristine. Although I haven't seen any yet, there is a possibility of a non-numeric version (one that starts with a "v" or one based on a Git ref) where a v prefix would not be easily distinguished from the actual version number.

from shields.

I don't think dropping the v is a problem. Ryan, are you attached to it?

On Thu, Feb 28, 2013 at 2:32 PM, Michael Rykov [email protected]
wrote:

I prefer the format [ gem | 3.2.0 ] because it still conveys the full meaning while keeping the version number pristine. Although I haven't seen any yet, there is a possibility of a non-numeric version (one that starts with a "v" or one based on a Git ref) where a v prefix would not be easily distinguished from the actual version number.

Reply to this email directly or view it on GitHub:
https://github.com/olivierlacan/shields/issues/5#issuecomment-14261915

from shields.

@olivierlacan @rykov Losing the v doesn't break it for me, but I do think that it's better with it. Regarding the concern for possibly non-numeric versions, 1) Neither rubygems nor npm will to play that well with those kind of versions anyway and 2) Someone who invested enough in putting a shield image on their project's Readme is going to be much closer to following Semantic Versioning anyway.

In summary, I vote for keeping the v, but it's not my top priority. Here is my current list of my priorities for participating in this thread.

1. Get rid of the red coloring in the version shield because it is too distracting and gives an unnecessary negative connotation.
2. Reduce the width (and noise) of the version shield, because it doesn't deserve such a large space in my READMEs. Remove the word "version" in the shield. Less is more.
3. Help convey as much meaning in the shield while keeping it concise (hence the desire for the v).

from shields.

+1 to the "drop the red" crowd. I'm a fan of the white on black proposed above, too.

Alternate idea on placement:

Many gem README's include a Gemfile line (gem "mygem", "~> X.Y.Z"). What if the badge covers that case, instead? (copy/paste is an issue with that, though.)

from shields.

Sounds like we're reaching consensus on the color. @olivierlacan, can you please update the SVG with the new background and I'll tweak the badges.

from shields.

+1 for grey-scale badges!

from shields.

Universal feedback on the new badges is that red background needs to go. Thus, I've temporarily switched to matching-green background while we iron out the grey ones.

from shields.

Awesome, thanks @rykov

from shields.