Cocoapod Badges

[fjcaetano]

Hello,

First of all, thank you for this project! It's amazing, simple and beautiful. I think you did a great job.

Based on it, I started a project for badges for Cocoapods (Objective-C package manager) and I've created badges for a pod (package) version and another for the platforms it supports (iOS, OSX). Don't worry, I gave you credits for the SVG used: http://fjcaetano.github.io/cocoapod-badges/

The guys from Cocoapods got super excited, and even created an API for me (since the first version was a little hack on their site :P) and they tweeted it to spread it to other developers. https://twitter.com/CocoaPods/status/342238471865372674

Now, if it's not asking much, I'd also like your help sharing it. Simply adding a link to my repo on your services list would be a great help!

Btw, I'm serving my badges dynamically, even though I'm serving them as svg and not png. I saw there's an issue on that matter, so why don't you take a look at my project?

[kookster]

Very cool.

It seems like it is not the same font, was that intentional, or did it give you issues?

It seems like you are serving up svg files but with a .png file extension (which confused me at first) and 'image/svg+xml' mime type. Haven't seen this approach before, it seems like this will work for some browsers, but IE < 9 probably won't. Not sure that matters, since I doubt many cocoapodders are on a PC ;)

The attempts to export to .png are meant to provide a static universally supported and consistently rendered representation of the badges, which an svg probably won't.

[olivierlacan]

@fjcaetano This is great. Thanks a lot for the kind words. I would refer you to the excellent work being done to create a Shields service to generate badges on the fly: https://github.com/olivierlacan/shields/issues/15

As @kookster mentioned, SVGs cannot be served as an image on GitHub. The GitHub team has explained to us it's a security issue for them to serve something that can basically be any XML document. It's possible that faking the extension might permit your badges to be displayed on a GitHub README for instance, but since the content-type doesn't match, that seems like something GitHub would be likely to adddress as a security problem. We should probably talk to them directly about this.

Basically, this is why the crux of our effort here has been aimed towards making it easy for anyone to generate PNG files from our standardized SVG source.

Regarding the shields you created, as @kookster also mentioned, the font is off. You can find the open source Adobe font Open Sans packaged at the root of this repo. The text alignment and padding within the badges themselves are also off, do you think you could get them to match the visual standard I established with the original design?

Now regarding the text on the badges — sorry, being a stickler is what prompted me to create Shields, can't help it — we've had a similar discussion with the people at Gemfury regarding having badges that said gem version | 1.2.3, it's unnecessary to have your badges say pod version | 1.2.3 when they could simply say pod | 1.2.3 or cocoapod | 1.2.3. Your platform badge presents an interesting problem, it's a really great idea, I'm just trying to think of how we could make something like that more standard, it seems like: platform | iOS would make sense, even if it doesn't specifically reference CocoaPods, since regardless of whether this is a cocoaPods package, it simply wouldn't work on any other platform.

Can a cocoaPod package be compatible with multiple platforms? Wouldn't that cause someone to have to use 2 or three of these badges?

Again, thanks so much for your initiative. I think this stuff is a great step towards making open source libraries easier to discover and deal with. 😃

[fjcaetano]

Hey guys, thank you for the response. Every opinion is worth listening when trying to improve. I actually did have some trouble serving the original font's static file because the browsers tried to append the path to the current page's host and not the badge service's host. It was weird and I couldn't find a solution, so I changed the font to Lucida Console because it was the built-in option that looked better (or less worse). Maybe that change was altered the texts' padding, but I don't have an eye for design, so I didn't notice it, sorry. Can you guys tell me exactly what is wrong? I will fix it. There was also an issue created in the repo by the Cocoapods' guys about that matter if you guys want to check it.

@olivierlacan you don't need to ask forgiveness. All designers should be perfectionists and shouldn't content to anything different from what they thought. The "pod" vs "pod version" vs "cocoapod" issue is valid and I'll put it in discussion. The other point, about using only "platform" is another matter. I did it the way it is because there may be multiple badges on a repo and I thought that specifying that that badge was about the pod's platform was important. Even though Objective-C is an Apple's proprietary code, therefore ObjC packages/libraries may only be available for iOS, OSX or both.

Btw, I've just created a milestone predicting a future release serving PNG images aswell as SVG. I'll let the option open to the user's will. But, for now, the SVG files served with a different mimetype and the .png extension are working on Github. If you look at the project's README, all the badges are being referenced directly.

[olivierlacan]

@fjcaetano from the looks of it you're actually displaying Times New Roman, not Lucida Console (which I have on my system). So it's completely ignoring the font. I'll leave the resident SVG experts here help you out, I've been out of it too long.

Thanks for considering the suggestions. 😉

[ackerdev]

@fjcaetano @olivierlacan Hey, nice! Glad to see these getting more usage.

I'll cite the same argument I gave to travis/gemnasium/gemfury when I originally suggested what the service text should be:
Your badges generate a lot of interest on their own, by merely being presented. Someone stumbling across these badges is likely to be intrigued by the API driving it and are likely to click the badge when they see it's a link to the originating service. The service text should be concise and understated, as the interested users will click to see the workings behind it if they want one for their own use. version | 1.2.3 platform | iOS is way more descriptive and useful to both the owners and incoming users than pod | 1.2.3 and more concise than pod platform | iOS.
Ultimately it's up to you if you feel that it definitely needs pod in the badge text, I just highly recommend considering dropping branding and letting the badge shine for itself.

As for the font family issue, I'm not sure why it wouldn't render as Lucida Console but I imagine it's falling back to default browser text like it usually does when it can't find a font-family. Unless you embed the font as an SVG font, you're not going to have much luck displaying it as an SVG with Open Sans (I haven't played with SVG fonts so you're on your own on that one, but there are converters that can create it for you so who knows). With this and the security issues/inability to cross-site embed SVGs means that your only real option is to convert them to PNGs serverside and serve those.

[fjcaetano]

Guys, I made some changes accepting your suggestions and tuned it a little bit to look closer to the original badges. What you think of the results?

type	iOS	OSX	iOS/OSX	error
SVG
PNG