accept offer of gh-badges

[chadwhitacre]

There's a new badges effort called Badge.me, at http://b.adge.me/. It's primarily motivated by a desire to make SVG a first-class citizen (cf. #80). @nathany and I had a call with @espadrine, the person behind that effort, and he is willing to contribute https://github.com/espadrine/gh-badges to Shields if we decide that we want it. Do we?

[duckinator]

A way to have SVG image tags fall back to PNGs (I feel this should be the default approach if we provide HTML examples that use SVGs): http://lynn.ru/examples/svg/en.html

[espadrine]

I'd like to invite input from @alrra and @mathiasbynens too.

Also, my blurry notes from the call.

[chadwhitacre]

@rkh Would first-class SVG support from http://shields.io/ be interesting to Travis?

(@espadrine Is that our question? :-) )

[chadwhitacre]

@espadrine And those notes are awesome. :-)

[espadrine]

More specifically: would everyone agree to using (and importing) the b.adge.me code as a starting point for Shields?

[espadrine]

@whit537 thanks! … Fighting blur with blur!

[rkh]

@rkh Would first-class SVG support from http://shields.io/ be interesting to Travis?

There indeed is: travis-ci/travis-ci#630

[espadrine]

@rkh Are you interested in having a centralized service for all badges, which would communicate with Travis, and serve badges in both PNG (for support) and SVG (for the future!)?

One thing we discussed was the possibility to serve SVG (with the correct HTTP headers) with the https://travis-ci.org/<USER>/<REPO>.png request, so that everyone is benefitting. It's used as an image anyway.

[nathany]

@duckinator That's an interesting img/svg hack, but unfortunately we're limited in what we can do by Markdown processors #34 used on sites like GitHub. Fortunately an SVG img src can work, we simply have no fallback for old browsers (which IMO should be fine given that we're targeting developers here).

@espadrine Glad we could chat today. I think we should make an effort to get various implementations under a new shields organization. #88. Personally, I'm more interested on hacking on Buckler, but if we run with b.adge.me as a basis, I'll still help out in other areas. It sounds like there are already a few people involved on the b.adge.me implementation, so that's a win overall.

[nathany]

As @Mikulas mentions, if we want consistency with existing badges (mixed static PNG and new SVG on a page) we are going to need to embed OpenSans rather than using Verdana. (hopefully with subsetting for file size) #88 (comment)

[espadrine]

@nathany Existing badges are not consistent with one another. Most (all, maybe?) use OpenSans, but maybe that font isn't the right fit.

Ignoring the aesthetics of it, using a web-safe font makes the image super-fast to load. For instance, http://badges.github.io/ uses an embedded OpenSans font, and each image takes about 2s on my Internet connection. Not embedding fonts means a <300ms load.

I discussed font issues on b.adge.me. Nothing is ideal, and I'd rather things were different, but Verdana seems to have the best balance. Download speed of the images should be a selling point, not a downside.

ps, @Mikulas, have you done some work on subsetting on-the-fly? I'm not sure how fast performing a subsetting can be.

[Mikulas]

Do note however that badges.github.io are forcing cache invalidation now as it's (was) a work in progress. As I proposed in #80 (comment), all badges can be cached on both server and client side, reducing the load time to basically zero (time of local cache read) for both implementations. I feel like it would be more appropriate to discuss browser support and appearance.

[rkh]

@rkh Are you interested in having a centralized service for all badges, which would communicate with Travis, and serve badges in both PNG (for support) and SVG (for the future!)?

That would raise security concerns for private projects.

[espadrine]

@rkh Are those security concerns a complete no-go? We would have no information about the repo.

https://github.com/secret/repo → https://travis-ci.org/secret/repo.png
                               → https://img.shields.io/badge/build-failing-red.svg

(Right now, you should think https://b.adge.me/:build-failing-red.svg instead.)

[Edit by @whit537: https://img.shields.io/badge/build-failing-red.svg is live now.]

[rkh]

Ah, with a redirect. That might actually work. We do that internally already, but to our API.

[espadrine]

@rkh Great news! Updated selling points:

• Removes blur on retina displays
• Low bandwidth
• Consistency of badges (even PNG / SVG)
• Flexibility (compatibility with PNG, if we don't use the trick I mentionned)
• Similar architecture to the existing one!

[nathany]

@rkh It was something I brought up with @whit537 in our first Hangout. Shields.io could know the location and build status of all Travis CI repos. Even if it didn't store anything, it would impact the privacy policy for Travis CI. (I see @espadrine has a possible workaround though)

I think the Shields.io service better serves non-commercial apps like GoDoc where we could've benefited from having HTTPS setup and paid for.

What would be most useful to Travis CI in terms of shared open-source implementation for badge generation? A CLI? A reusable library? Offline badge generation via a web app? (in addition to the styling consistency/guidelines that @olivierlacan pioneered).

Fyi, one of the plans for the service would be to offer some form of analytics #93 to end-users, which may be something Travis CI and other companies are less interested in implementing.

[rkh]

I think in general it would be totally fine, possibly even the best solution for us, to keep serving status images on our side, an easy way to generate them semi-automatically would me very helpful, since we could then generate them whenever we update our build states. Library, CLI, web service would all work for us, I guess web service would be easiest.

[alrra]

I'd like to invite input from @alrra and @mathiasbynens too.

@espadrine my contributions where very minimal, so from my point of view, all decisions are up to you and @mathiasbynens.

@whit537 as for the design part discussed in the video, yesterday I've send an email to @espadrine asking him if he was considering a design change for http://gh-badges.herokuapp.com/ (now http://b.adge.me). The email also included a link with something I put together really fast (just wanted to know where to start from), something that wasn't really satisfying for me, hence why it wasn't on GitHub. So, no harm there, as I really didn't have the time to start any serious work on that part.

[nathany]

@espadrine As per #88, would you like to transfer https://github.com/espadrine/gh-badges to under the badges organization https://github.com/badges.

You already have admin access which should just work. Feel free to create a push/pull team for gh-badges specifically and invite @mathiasbynens, @alrra and anyone else.

Let me know here if you run into any issues. Thanks!

[chadwhitacre]

Thanks for being flexible, @alrra. You'd be welcome to chime in on #92. :-)

[mathiasbynens]

👍 to centralizing all the badge services into one!

I’m biased towards simply re-using the existing b.adge.me codebase for Shields because it already does everything we need:

• the output is heavily optimized, super-compact, valid SVG
• PNG is supported as well
• written in Node.js

[olivierlacan]

First of all thanks for @nathany and everyone for centralizing implementations here. I think I'm going to focus on refining the specification because so far I can't remember one implementation getting everything just right. Instead we have bits and pieces everywhere.

I'll admit it's frustrating that we keep switching target implementation (new language, new features) instead of sticking with one and finishing it. If we're going to cache things so heavily then maybe the speed of generation doesn't matter as much?

All I really care about is if a badge generator implementation:

1. follows the specification
2. has an intuitive API

I wonder if the API design is something we should standardize since everybody seems to be coming up with slightly incompatible variations.

@espadrine Can you check out the newly added Specification and more specifically the Aesthetics section where I discuss the reason behind choosing Open Sans over Arial or Verdana. @ackerdev and others spent quite a bit of time trying to figure out a way to deal with fonts in SVG in a lightweight way.

I agree with you that SVG can be smaller but not without the drawback of not being able to ensure how the font will be rendered by the browser — which can affect legibility and consistency.

The reason we used an SVG template but a PNG output was purely pragmatic: PNG will most likely be displayed exactly the same across all browsers and operating systems, which circumvent all the issues relating to imperfect SVG support (although they'll hopefully be fixed):

When it comes to resolution dependence, another practical solution was pixel doubling (or 2x) for high DPI (retina) displays. Any chance you could provide a 2x PNG fallback?

[mathiasbynens]

@olivierlacan Pixel doubling is not a good solution — it doesn’t scale (pun not intended). There are already @3x displays out there.

If we want to make the SVG badges first-class citizens, we should only provide PNG as an inferior fallback, nothing else.

[espadrine]

@rkh Part of @olivierlacan's goal is to have visual consistency across badge vendors (not just Travis, but also Coveralls, etc.). Having a single service ensures that, so the redirect option is probably the best.

On the other hand, I'm curious what you think about the option of serving SVG upon the https://travis-ci.org/<USER>/<REPO>.png request, so that existing badges benefit.

[espadrine]

@olivierlacan The current format used in b.adge.me looks like this.

(Top: Firefox. Bottom: Chrome. On Linux.)

The issues we mention about browsers are things that we struggled with, not things that are an issue in the current implementation of the badges. For instance, the text shadow is better served with a filter, which has a few bugs in browsers. That text shadow is not required for legibility (indeed people actually complained about it making it harder to see), so we took it out.

I should mention that what we should strive for is consistency between badges, not the interdiction of visual refreshes. In other words, all badges should look the same at every point in time, but not between different points in time.

I am curious what @ackerdev found out about fonts. Presumably, embedded fonts and subsetting, which is already something we considered in b.adge.me. We are not striving for a specific result, we are targeting a good result. In that case, bloating the image would only be necessary if it had a huge impact on legibility, which it does not.

Having a particular font is irrelevant, too, if all you target is legibility — you merely want a legible font. Assume you take Verdana. If the computer you have does not have Verdana installed, why should we assume that he has a good Internet connection? A user without Verdana is rarer than a user without a robust connection… Sending a huge amount of data to display it just right does not make sense, while the fallback font may very well be just fine. Indeed, the place where there are the least number of Verdana users is Linux, where the default font usually is DejaVu Sans, which looks very similar to Verdana.

[ackerdev]

@espadrine Yes, embedded fonts and subsetting were possibilities when we were considering delivering SVG instead of converting to PNG for delivery. Since we were no longer going to be delivering SVG, I stopped looking into it and we wouldn't have that problem since could just reference the font installed on the image server.

When you work with fonts being shrunk to the limit of their legibility, and needing consistency of display across systems, I think having particular font is actually a pretty big concern. Some very similar fonts (eg. Helvetica/Arial, Verdana/DejaVu Sans) will look very close typographically at their intended sizes, but significant differences can be found at extremely small sizes like we use.

[nathany]

@mathiasbynens I think we're all in agreement to use gh-badges as a basis. Let's get the repo over here and organize the team.

I'd like to keep this discussion on visual design of the badge and API design going in separate issues when we close this off. Further, let's have a badgedesign label with independent issues for fonts, colours, etc.

[espadrine]

@nathany I'll transfer the repo tomorrow. A few last questions.

• Will the issues be transferred as well? (I have never transferred a repo before.)
• Should we have a policy for the website update? (I tend to favor "release early and often".)
• Do we have a code review system? (Maybe only have one from launch on — idea: always have at least two folks that know about a particular change at all times.)

[nathany]

@espadrine Everything will be transferred.

I would like you to head up the development #96 of gh-badges implementation, making those decisions around code review, style guidelines, testing, etc. But I agree these are all good things. Also see #99 contribution guidelines for this repo.

I don't know how many people are currently using img.shields.io and what the transition plan will be. Let's open a new issue for that #101

[nathany]

Listening to the tail end of the conversation on Tuesday, it sounds like we should still discuss our Technology Stack, including the HTTP server, badge generation, and potentially a backend for end-users to sign in for analytics, etc.

Shall I start a new issue to formalize that decision?

Should we evaluate current implementations? (retina, performance, memory, stability, code quality, test coverage)

Otherwise, gh-badges has moved under the Shields banner, so we should be able to close this issue.

[nathany]

If @espadrine is stepping up as lead developer #96 then I'm happy to come back to the technology stack issue whenever he deems it necessary. For now our first priority should be getting gh-badges in production with the remaining issues worked out (adhering to @olivierlacan's specification for badges, for one).

Closing this issue off. Thanks for coming on board @espadrine!