Add 'unknown' status for Travis shields

[ackerdev]

@joshk has requested a 5th shield for the travis-ci set.

Create an 'unknown' variant of the travis ci shield (grey).

(Also draft a set of shields labeled 'travis ci' instead of 'build').

[joshk]

<3<3<3<3

On 3/02/2013, at 3:21 PM, Nicholas Acker notifications@github.com wrote:

@joshk has requested a 5th shield for the travis-ci set.

Create an 'unknown' variant of the travis ci shield (grey).

(Also draft a set of shields labeled 'travis ci' instead of 'build').

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

[joshk]

Awesome work!

Let me know where you have the 'travis ci' drafts and I can talk to the team about it :)

You rock! Thank you so much!

[ackerdev]

@joshk Sure, though the draft will have to wait for a bit as I'm busy. I suppose I'll post them here and ping you and olivier to talk about them, if that's alright with you guys.

[joshk]

Sounds great to me :)

<3<3<3

On 4/02/2013, at 4:34 AM, Nicholas Acker notifications@github.com wrote:

@joshk Sure, though the draft will have to wait for a bit as I'm busy. I suppose I'll post them here and ping you and olivier to talk about them, if that's alright with you guys.

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

[ackerdev]

@joshk @olivierlacan

For what it's worth, I vote for it to stay as 'build'. Travis is already the head honcho on CI for those in the know, and I think 'build' both helps people understand what it's for and makes them curious who's behind it.
Let me know what you guys decide on. :)

[gonzoyumo]

This is a good question. Having the service name in the badge seems important to me too.
As there are different services providing same "kind" of badges, when using these open versions, services loose their identity. Though I agree it's also important that badges say what they stand for... but it will certainly make them way bigger if they need to mention both :(

[olivierlacan]

As I've already argued in here(), I favor the "function-based shield" over the "brand-based" one:

Yet, I think it makes more sense when used on a third-party website with other services (like RubyGems, Code Climate, Gemnasium, etc.) to not necessarily draw attention by having a different style for every service. It could quickly turn into an ugly little patchwork, and people might refrain from using them.

It's really neat that so far most of these badges haven't been used as ad banners for each service and instead focus on the value they're providing to the repositories (their visitors, contributors, owners).

Code Climate is an exception, but talking to @brynary he mentioned his intention was to display the repo's GPA inside the button eventually. We talked today as I released Shields and he was actually in the process of doing that too.

I would understand completely if each service looked after their best interest (or their best stylistic choices 😃) by trying to brand their badges differently, but when you think about it for a second the reason I was attracted to Travis in the first place was that I waas curious about that "build status: passing" thing on some of my favorite repos, and I wanted to know what it meant and what was powering it.

What I mean to say, in short, is that despite homogenous badges, I think the value each services provides is going to shine through. That is, as long as the button aren't illegible blurry mess. 😺

That said, here's a potential compromise I'd like @ackerdev & @joshk to consider:

I obviously don't have the original Travis mark (although I shot an email to Travis support to ask for it) but I think this is a more subtle way to differentiate "build" badges while retaining the "function-based" that makes them so. It's indeed possible that multiple services (that all provide continuous integration, for example) might be tempted to use the same shield and therefore create confusion. I'm guessing that's the underlying worry that prompts people to ask for branded badges — look at me trying to analyze @joshk over here 😉.

[ackerdev]

@olivierlacan Certainly a better option than the semi-ambiguous travis ci | failing badge.
I would consider drafting one for each service though, as certain logos may not work nearly as well as Travis'. (Gemnasium's is largely horizontal, which would need extra space to look legible, and gemfury's wouldn't look so well at small sizes)

I both understand and agree, to a point, the want & need for branding on the badge. However, I also have the personal belief that it creates more clutter than it's worth; I learned about Travis and gemnasium and codeclimate not because their logos or names were displayed on the badge, but because of the functionality of the badge–"who is providing these statistics?" is the question that spurred my interest and visit to these services, not a name or logo. I think that there's more value to the clarity of the badge than to display the mark of the service behind it, because I am of the belief that the curiousity behind it would cause the visit to the service in and of itself.
(I do also understand that I may not be the only one who thinks that way, for the record.)

Heck, I would've said the same thing for code climates' if it wasn't for the argument that GPA was an American-centric concept that may not translate perfectly to badges, and that their name acts as a description of the score. That's why I would consider theirs a noteworthy exception.

(To be clear, I'm certainly not against trying out badge branding and if it looks and works well along something like olivier's concept, I'm down for it. My word certainly isn't end-all-be-all, just trying to cover the bases and thoroughly think this one through.)

[madrobby]

It would be lovely to provide the badges as SVG (only). All modern browsers can handle those just fine and you get automatic retina/high-density screen support. Plus it's much easier to customize (more colors, and even i18n would be easy).

[joshk]

Hey Guys,

Sorry for my radio silence, been fighting VMs and all that fun stuff.

In short, 👍 on 'build' as the points made about how it is clear what the button is about and how it helped people discover Travis make complete sense. Also, 'travis ci | failing' reads like Travis is failing. :)

I don't think the logo version works well, and to be honest, what you have created is miles better than what we currently have, so we can always make improvements down the line.

@madrobby, the current set of new images is listed on https://github.com/olivierlacan/shields, any advice on image quality and how easy they are to read?

Guys, I heart you big time! We will definitely blog about this, this is super amazing!

❤️ ❤️ ❤️

Josh

[ackerdev]

@joshk Can't wait to see them in the wild!

Also, 'travis ci | failing' reads like Travis is failing. :)

Hah, that's what I was trying to say. :)

[ackerdev]

@madrobby Well, that's why I put the effort into contributing the SVG versions. They still need a few tweaks to ensure they display properly at all sizes (there's some issues that I had to fudge for pixel-perfect PNG output, making the un-rastered equivalents have a few oddities to them that I plan to fix).
There's also some things that need to be done to make them portable, such as embedding the font. They're just not ready yet, though I certainly will make an attempt to reach out to shield-users when their SVG equivalents are considered production ready, and would love to see them get used.

Makes me wonder a little bit about how many people on github might be using IE < 9 though... 😨

[joshk]

@ackerdev so what do you think it would take to make these images production ready? (in your eyes)

I think we would be happy to move to them very soon once they are ready :)

[ackerdev]

@joshk The PNGs are perfectly ready to go as is.

The SVGs @1x I believe have just one issue, which is that the text is shifted up and to the right by 1px.
I haven't checked the SVGs @2x and @3x, so I just would need to check that say, the gradient proportions still look right at the increased resolution.
And then the bigger issue with the SVGs is making the font portable, which I've done some reading up on in regards to this issue but I haven't taken a stab at it yet.

So, down and dirty of it is:

• Implement PNGs as soon as you want
• The SVGs aren't quite ready just yet, but when I do get some time to spruce up the SVGs, I'll make an effort to reach out and contact services that we supplied shields for

[madrobby]

You can't make fonts portable—you'll need to use outlines.

[ackerdev]

Unless you know something I don't, I believe you're incorrect there. From what I understand you can embed SVG fonts into an SVG.
I should be able to convert OpenSans.ttf into an SVG font and link to it externally or embed that into the SVG file itself. I've read that Firefox doesn't play well with cross-domain font links in svg so embedding looks to be more promising.

Unless there's a browser compatibility or license issue I haven't investigated yet I believe there are other options than converting to outline.

[madrobby]

@ackerdev The main issue is that you will end up with giant files (there's no reason to include the whole font, especially given the use case to serve the SVGs on a web page). It's much better to serve just polygons—which also avoids any incompatibilities across font rendering engines.

[ackerdev]

@madrobby You can include only the font glyphs you want. I would at the very least least cut it down to un-accented alphanumerics and '.', and for static badges you can even cut it down to just those glyphs. Don't know enough to say anything about incompatibilities.

Regardless–I haven't taken a good look into it yet, and will have to determine whether the file size becomes too unwieldy or if there are ways I can optimize it. And as we both know if all else fails, outlines are still there.

I'll be making an issue for these tasks in the coming days and going over the process I'm using, so if you're watching this repo you can always chime in then if you know more than I do. But I'll be exploring the different options and making a decision from there.

[olivierlacan]

@madrobby & @joshk do you like the solution we ended up with regarding using <img> tags whenever retina shields are wanted?

You can simply offer people the Markdown tag for a low resolution shield and an image tag that will display a shield compatible with both retina & non-retina screens.