Hacker Newsnew | comments | show | ask | jobs | submit login

It's an interesting idea but there are a couple of things you should think through before taking it too much further. I don't think depending on partnerships is necessarily horrible, but what I'm trying to determine is what the benefit for the partner is. In the Stack Overflow example, Stack Overflow has to create the logic of when to award the badge, create the badge asset (e.g. what it looks like), and call your service at the appropriate time. So far they've done all the work for your benefit. What do they get in return? This is the kind of thing you might want to think about otherwise it's just a glorified/unified badge gallery, which won't be terribly interesting to many people.

I also think your example of other services limiting behavior depending on badges gained on other sites to be unlikely. From the consumer's perspective, a reputation system has a lot of value in context, but that's very different than saying that my reputation on one site has value on another. From the partner's perspective, I find it unlikely that I would build a site that depends on my audience's behavior on someone else's site.

I don't think these things are deal breakers, you just have to target it a little more precisely. Nice work so far.

Integrate this with a selection of a few dozen no-programming-required badge templates and a badge/achievement designer, though, and you could have something.

Example: there should be a quick fire-and-forget Javascript method to increment a per-user arbitrarily named variable that you keep track of, and then when you exceed some threshold of that, you get a badge. That allows you to use one system to support everything from "Slay 100,000 orcs" to "Print out 75 bingo cards", with negligible work from your API consumers. The fact that it is negligible work creates value whereas your base offering (show that you've slain 100,000 orcs on your teaching bingo site profile! Booyah!) does not.

Other easy things to measure are stickiness (time since registration), collecting all of a set of API calls, etc (For example, in the hosted badge designer, you could say "A Dragonslayer is anyone who submits any [dropdown: two] of the following events: killed-red-dragon, kill-blue-dragon, and kill-green-dragon. Then customer site only has to fire killed-#{monster.name} as appropriate, and boom, dragonslayers.)


I must admit, this type of thing as you and dflock have described has always been in the back of my mind. I kept tell the thoughts to go away because thats a pretty big undertaking. Fortunately, I actually have experience building customer facing rule engines.

This is dangerously tempting to work on. Should I go for it? Perhaps I would need to provide both methods of awarding badges. I dont see StackOverflow.com wanting to re-implement their badge system rules in the KaBadge system.


I would agree with some of this - as a potential partner site, I would sign up (and maybe pay?) if you were providing me with a complete reputation system, as this would save me coding my own, ala Steam and XBLA Achievements. Is this in the game plan?


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact