Welcome to Cykod. We are a fully-integrated, self-funded web-development startup located in Boston, MA.

Cykod Web Development and Consulting Blog

Thanks for the Semantic Web Facebook (I still don't like you though)

Everyone is talking about what a bunch of evil privacy destroying, soul sucking jerks Facebook is. There's even a quit Facebook day. And I agree. I like my privacy and I would love something like Diaspora (despite their curse) to move the social graph out of one corporation's greedy hands.

What seems to have been overlooked by the tech media however is what an absolutely fantasmagastical (I'm really that excited) thing Facebook did to push us all towards that wondrous pie in the sky of Web 3.0.

With OpenGraph, we have meta-data now. Real, usable, indexable, meta data.

With OpenGraph, a web-standard that Facebook released to help it pull information from web pages people "Like", we now have metadata. Real, usable, indexable, metadata. Facebook is throwing it's full weight behind OpenGraph by making it invaluable for maximizing the usefulness of it's new unit of social currency, the Facebook "Like". If you haven't peeked at the Open Graph Protocol, take a quick look.

Yes, it doesn't do everything, but notice how simple it is. There isn't even a mention of the words "semantic" or "triples". It's something that's very much targeted at being useful and usable. It's something you could explain to your boss and they'd understand it.

Facebook released open graph at F8 in 2010. It's already showing up all over the Web because of the market weight of Facebook (I noticed it in the HTML of GoodReads pages.) While OpenGraph is based on RDFa, OpenGraph and RDF are very different beasts. RDF has been around for most of the decade but hasn't gained much traction on the commercial Web. If you want to understand why, try to read the primer or even the primer primer (The fact that someone even felt compelled to write a primer primer speaks to the issue - RDF is complicated to understand and implement)

So here's the awesome part: everyone's implementing OpenGraph for Facebook, but us Web Developers can hitch our metaphorical Poon to the back Facebook's speeding truck and get to the same destination: the semantic web.

There's already libraries in a number of languages to support open graph, and using them (at least the Ruby one) is dead simple.

require 'opengraph'
movie = OpenGraph.fetch('http://www.rottentomatoes.com/m/1217700-kick_ass/')
movie.title # => 'Kick-Ass'
movie.movie? # => true
movie.image # => 'http://images.rottentomatoes.com/images/movie/custom/00/1217700.jpg'

[To put a slight damper on Unicorns and Rainbows tone of this post, the opengraph Gem didn't want to pull meta-data from the GoodRead's site]

Contrast this with an actual API - even a simple REST one like GoodRead's API: you need to get an API key, limit yourself to 1 request per second, and handle the data that comes back on a per website basis.

Perhaps more importantly, you are bound by the terms of use of the Website's API for anything you pull down. In the case of the GoodReads API, you need to remove anything you pull from their API in 24 hours. In the case of OpenGraph, while I'm sure the legal responsibilities are a little murky - you can pull and store data as you like provided you abide by fair use (e.g. Google doesn't need to remove all data it scrapes from the Web every 24 hours).

Now something like oEmbed is obviously a competitor to OpenGraph, however oEmbed is actually a lot more work for a website to implement than OpenGraph and there's not the same motivation - Facebook "Likes" -  driving adoption. We use a (great) third party provider called Embed.ly to support a lot of extra sites that haven't implemented oEmbed, but truthfully, it would be nice to be able to drop the middle man and pull meta-data straight from the source.

OpenGraph is the classic case of the Bazaar functioning better than the Cathedral.

OpenGraph is pretty new, and given Facebook's willingness to change and tweek constantly, I'm sure there's more usefull stuff that will be added to the protocol soon. So even if the semantic Web isn't here, we're at least pointed in the right direction. OpenGraph is the classic case of the Bazaar functioning better than the Cathedral. I'll take a quick and dirty approach that's actually implemented by millions of sites than a "perfect" idea that no one can understand, and that's exactly what OpenGraph is starting to get us. It may be Web 2.5 - but it's here today.

Posted Thursday, May 20 2010 10:22 AM by Pascal Rettig

A band-aid for the comments conundrum: Developing a Tilder filter

I made the mistake yesterday of reading through the comments section on a Boston.com article. I should know better and I quickly regretted my decision.

The comment sections on websites these days suck either because they are completely devoid of any sort of intelligent thought (poster child: YouTube) or because people really enjoy expressing strong opinions tangential to the subject matter just to make themselves feel smarter (poster child: Slashdot)

For the former problem there's not much you can do - to have a good conversation you need people willing to write coherent sentences. For the latter problem, unfortunately, it's not a question of being able to write the comment, it's being willing to take the time to read the article and add something productive to the conversation.

Now, the problem may stem from us internet-friendly millennials who think we're terriffic on account of our extensive collection of after-school sports trophies and refrigeratored A+'s, and so are convinced that the world really, REALLY needs to hear what we have to say, regardless of what we're saying. Or maybe it's a universal issue and people just like griefing. It's tough to tell.

In any case, for our purposes people who read blog posts fall into three overlapping categories: people who want to write comments, people with something intelligent to say, and people who actually RTFA. Ideally, you'd like the comments on your blog to come from only the intersection of all three of those groups.

What often happens, however, is that you just end up with the difference of the first group minus the other two. People who have RTFA will scroll down to the comments, see all the comments that say "You are an idiot and should never have children" and decide to move on. The other group - people with something intelligent to say, will often make a great comment that adds nothing to the subject matter because they can't be bothered to RTFA to the end. Furthermore, Austrian goats are my favorite animals!

As a partial solution to this problem we've come up with a concept called the Tilder filter that works like this: somewhere in the blog post, preferably near the middle, there needs to exist a complete non sequitur. Something that's really out of place and will catch the attention of anyone who reads the post.

Next, as soon as someone tries to submit a comment the system sets a cookie via javascript (more on this in a second) and darkens the screen with a lightbox-like popover obscuring the entire page. On this popover is a multiple choice question with 8 or so answers which the user has twenty seconds to answer. The answer is of course the non sequitur mentioned earlier.

If they get it wrong - too bad. No comment for them. Of course they could remove their site cookies and try again but at that point they are going to be so angry that their comment will be easily discernible and moderated (e.g. "Your site sucks, I just lost my f#$@%ing comment you worthless pile of ..." and so on)

Now regarding the cookie, since we set a cookie the minute they press submit, the system can black out the page if they bring it up in another browser and disable the comments form after they failed to answer the question correctly the first time. This could all be done very simply in javascript as a proof of concept, while a real implementation would need some server side support.

I'd love to hear feedback on the idea, provided, of course, you've taken the time to read the full post.

Posted Thursday, May 13 2010 07:36 PM by Pascal Rettig | Development, Troll

Thriving in the coming game mechanics hype cycle

It was the famous Jesse Schell video from DICE 2010 that finally convinced me that Game Mechanics on websites were here to stay. I had hoped once people got tired of mayoring-up and badges it would die down, but that video opened my eyes to the fact that it's here to stay.

Why wasn't I convinced before that? I think it might have something to do with the fact that currently implemented game mechanics don't particularly engage me. I love video games and play on Steam and Xbox but have never gotten into achievements, so I idiotically assumed that since I wasn't that interested most other people weren't either. Some recent conversations I've had have clearly indicated that's not true and that a significant portion of the population can be manipulated to change their behavior via achievements.

Two things someone said in particular amazed me:
1) People will buy a crappy movie knock-off game because they intentionally make achievements easier than normal games
2) People will pay to skip portions of the game to keep up with their friends (Farmville, WoW, etc) but don't think their friends do the same.
(Notice neither of these are actually "fun." In fact, they both constitute, in a loose moral sense "cheating")

Just like "niche social networks" were the big thing a few years ago game mechanics are the new hotness.

So I now very much believe, as someone poignantly wrote, Game mechanics are the new black. We are already heading into the overhype stage. Just like "niche social networks" were the big thing a few years ago game mechanics are the new hotness. The idea of "Game Mechanics" has filtered down to the client level and clients are asking for them. However, just like the "niche social networks" few of the multitude of projects are going to bring real innovation to the space for a period of time. Why? They don't need to - clients are going to be asking for plain-jane points and badges because that's what they've seen work - so most developers aren't going to push back and try to innovate because that's not what client want.

Most developers aren't going to push back and try to innovate because they don't have to and that's not what the client wants.

Simple game mechanics are going to sprout up everywhere soon and it's going to get painful. If you think constant foursquare twitter updates are already a pain - extrapolate that exact same idea to every area of your life. To use the example from the Schell talk, want you get your teeth-brushing-points? You'll have to let your your wifi enabled toothbrush tweet every time you brush your teeth. "Just made my teeth extra clean with #colgate!"

At an abstract level, one of the reasons for the success of points, badges, etc is that they guide our efforts. They place a clear valuation on our time and say "You can do A or B or C, but B is worth 2x as much as A and C doesn't get you anywhere." They are an effective way in our mentally-exhausting media saturated lifestyles to cut through the noise to a clear quantitative signal and feel rewarded for our efforts with tangible results. Once they are everywhere, however, their apparent value is going to decrease as the noise increases.

The argument for implementing basic game mechanics is that whether everyone's overdoing them doesn't matter because they will help engagement, expansion and retention on my site. That's unfortunately not necessarily true and let me try to explain why:

We call these things game mechanics but they aren't really. They are meta-game mechanics. Mechanics that operate on a level outside the game. For example in a 3D FPS, the game mechanics would be the running around and the shooting of aliens in the head. Your score and achievements are meta-mechanics outside of the game. Shooting aliens is fun. Getting points for doing so isn't, in and of itself, at all fun.

In a similar fashion, points and badges on Web sites operate outside of the core feature of the website. You could argue that on a site like FourSquare things get a little muddled - but even there the "Game" is the tips and location aware check-ins - the badges or mayor-ships you get for doing so are a meta-mechanic.

(As an aside has anyone come across a meta-meta game mechanics website? A site that gives you points for other points that you get on other sites - I'm sure there's at least one out there already)

To get back to why a focus only on the meta-mechanics might be bad, let's take the example of MySpace and facebook. The Game Mechanic, aka the "meta" is the number of friends you have in your social network. For a lot of MySpace users that was all that there was to it - get as many friends on your account as possible (well, besides ugly wallpaper and writing idiotic shout-outs on people's walls.) Because that was the game, MySpace grew like crazy, but once people got tired of adding friends it was done [a gross over-simplification I know]. Facebook was much the same at the beginning, with a focus on adding friends, but then they innovated the hell out of the game. Making it actually social by pushing other user updates to your wall and adding third-party applications kept users engaged and Facebook growing like crazy.

So a game mechanic can work to your advantage, but only if you don't let it dominate the show.

Companies shouldn't really care about Game Mechanics, they should care about Viral Mechanics

Sachin Agarwall made a great point in his "Don't be a douche" Barcamp Boston presentation. The Slides are sort of hard to follow but here's the gist: companies shouldn't really care about Game Mechanics, they should care about Viral Mechanics. How the game mechanics promote viral expansion of the user base is what is actually important to the bottom line.  Just throwing a couple of points into the system amounts to Cargo Cult Game Design. As Agarwall pointed out, the issue is that at some point notching the viral mechanic up in favor of the company will make it annoying enough that users will turn it off or leave.

To look at it another way, the fact that the simple game mechanics most people are talking about put the focus on the meta means that when it's all said and done they actually take away from the core of the game. As Jeff Atwood wrote a while back: Meta is murder. Even though he was talking about online forums and discussions, I think he had it right.

The tagline from FourSquare is: "Foursquare on your phone gives you & your friends new ways of exploring your city. Earn points & unlock badges for discovering new things."

FourSquare is more about the meta than the game...

if they don't provide real value, people will quickly move on to the next flash in the pan

Yet I never hear people discussing the great things they found or discovered on FourSquare. I have seen and heard plenty about that second part. Go to http://foursquare.com/ and watch the "recent activity." What is the Tip to Badge/Mayor ratio you see? The times I looked I saw a lot fewer Tips than other stuff. FourSquare is more about the meta than the game. That's obviously working well currently, but I wouldn't count on that continuing if they don't provide real value. People are always quick to move on to the next flash in the pan.

To go back to the Atwood blog: "If you don't control it, meta-discussion, like weeds run amok in a garden, will choke out a substantial part of the normal, natural growth of a healthy community." And yet with Game Mechanics we are intentionally adding meta-elements into our systems and making the conversation revolve around them.

Now as businesses we like the meta-elements because they take advantage of people's strong innate desire for personal-validation and self-aggrandizement, but more than just muddying the waters, they also unfortunately bring some bad behavior into the mix.

To put it simply: if it's set up like a game, people will play (and cheat) to win.

When users are playing against themselves, you don't care that much if they cheat, as engagement is king on the web and if plays are taking the time to cheat you're actually probably ok with it as a site owner. When users are competitive with other users however, bad things can happen. I stay away from Digg these days because the game part of it has skewed to dramatically favor the all-powerful Digg superusers and that means that it no longer feels like a balanced, social environment.

Summary / TL;DR:

Game Mechanics - at least the simple ones that people are talking about like points and badges, aren't actually the mechanics of the game at all. They are the meta-mechanics that surround the game built to induce behavior inside the game. But there's no reason it has to be that way, and so where you should focus your efforts to avoid launching a dud as we roll through the game mechanics hype cycle is on making the core of whatever system you are building more game-like (put simply, fun) and not just toss a thin-veneer of simple game mechanics around the outside. Read the literature and blogs on the subject and brush up on what makes a game fun.

Try to make sure your app is a game worth playing in-and-of itself before resorting to tricks.

I love the Mega-man games because unlike some other games that just pat you on the back when you complete a level, in Mega-man you get a kick-ass new weapon. It adds something of value inside the game. FourSquare's push to have mayorships translate to perks in real life is a great piece of value getting added, but unfortunately, because it's an out-of-game perk that is also a scarce resource it encourages cheating that has negative effects (think FourSquare wants to play check-in cop?) My opinion would be to try to make sure your app is a "game" worth playing in-and-of itself before resorting to those types of tricks.

And in any case, you'll have plenty of chances to do in-real-life rewards next year when we roll through an augmented-reality overhype cycle.

[ Update 5/20: Case in point "Badge" support on HuffPost ]

Posted Monday, May 10 2010 11:18 AM by Pascal Rettig | Development

Ugly Abstraction, or "Just one more option parameter"

One of the mistakes that I was (and probably still am - but being aware of the problem I think has helped) guilty of was the crime of trying to make one piece of code do too many things.

Like a vacuum cleaner with too many useless attachments that don't work correctly and keep getting lost, expanding on one function or piece of code by adding too many different conditional branches leads to a quick and ugly code death. At first glance, adding options might seem like vintage DRY - if you already have code that "almost" performs a certain function, why not add a couple of lines and a parameter or two to make it do a little bit more. In reality though, a hundred and one conditional branches are the quickest way to take an ugly-stick to your code. The next guy forced to look at the spaghetti that you've written will probably just end up quitting so that he doesn't have to maintain what you've written.

The better option, which is still DRY but also allows for separation of concerns is to extract the shared functionality separately and then invoke both your old function and a new function to get job done. To give a simplified example (extracted from some old PHP code I looked at recently), what's better:

function generate_table(&$data,$wrap_in_a_div = false) {
$table_info = ... // Generate your table
if($wrap_in_a_div} {
return "<div>" . $table_info . "</div>";
else {
return $table_info;



function generate_table(&$data) { 
$table_info = ... // Generate your table
return $table_info;
function generate_table_in_div(&$data) {
return "<div>" . generate_table($data) . "</div>";


Ignoring the triviality of the example, for my money, the second one is liquid gold compared to the first one. There may be some perfectly valid need to have a table in a <div> tag sometimes and not sometimes, but the table generating code shouldn't worry about it because it's not it's job. If it turns out you need a whole bunch of junk occassionally wrapped in a <div>, you can down the road extract a generic wrap_in_div method and refactor generate_table_in_div to us that method.

Posted Friday, May 07 2010 11:45 AM by Pascal Rettig | Development, FNEO