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

Cykod Web Development and Consulting Blog

Keeping it Lean at GamesForLanguage.com

The word "Lean" has come a long way from being primarily associated with ground beef and toned abs. For people in the startup community, lean has become synonymous with one thing: The Lean Startup.

Combining the central tenents of both the Agile and Customer Development philosophies - many of the ideas behind the Lean Startup focus around one core idea: minimizing time through the "Build, Measure, Learn" loop.

When we started talking about doing GamesForLanguage we really only knew one thing: we wanted to build an online language learning tool. This idea had been percolating for a loooong time, and we had actually bought the first domain for the site, Games4Language.com way back in 2004.

How we were going to do that and what exactly such a tool would consist of, we didn't presume to know. We also didn't even know if people wanted to learn languages by playing games. Now, we strongly suspected they did given the popularity of gamification currently going on in all walks of life, but that was just a hunch.   Based on a quick survey of friends and family, we decided to give the idea a shot. 

Prototyping, round 1:

Our first step was to put something very basic in front of people and see their reaction - the goal was to see if people would play through a quick scene or get bored and quit. Since one of the most important aspects was to be able to build something and get feedback quickly and incrementally, we made one overarching decision: each level would consist of a number of "mini-games" that would be independent of each other and could swapped around. This was an absolutely essential decision as it allowed us to put something together very quickly and test individual bits without the context of an entire system (one our original idea was a much larger-in-scope RPG type affair)

We sat down, hammered out some ideas for basic scenes and then threw together a quick-as-possible ugly-as-sin demo in an afternoon.

I threw that demo up on a easy to get to url and we spent the next few weeks harassing everyone we could to go through any play the game while we watched. At this point all we had was a static shell of a game along with some recorded voices and some Javascript tying everything together. We didn't have any real data, but were trying to get a feel for what people liked and didn't like by shoulder surfing. Starting with 2 "games," we kept adding and modifying until we had 8different screens and an online recorder where people could record and play back their voice (one of the early requests from players).

Here's where we were after two weeks of prototypes (warning it will play sound on you):

We learned a lot from just watching a handful of people play with the prototype. The most important lesson, which gave us hope for the project was that people genuinely liked the games. The flip side, however, was that anything that wasn't in the form of the game caused people to lose interest on much more quickly. 

The lack of interest in anything that wasn't a game presented a little bit of a problem. We had intended to alternate between "teaching screens" - those explaining words and phrases - and "game screens" where users would practice. Well, we went back to the drawing board and decided we would see if we could come up with a solution and now the only screen that's not a game of some sort is the dialog itself. Event that will likely become a game later on when players have more vocab under their belt.

Protoyping, round 2:

At this point we went to the (literal) drawing board and our designer put together a fantastic look-and-feel for the game. Design partially in place, we went back and shoulder-surfed some more. The results were very encouraging for the basic premise of the project: that people like using games to learn. Furthermore, we realized that exactly what constitutes a "game" more or less comes down someone deciding that what they are doing is a game. If it looks like and feels like a game, it must be game.

Check out the music game genre (Rock Band, Guitar Hero, etc), which consists of pressing plastic buttons at the correct time - and yet an entire industry grew up around it because the type of game flipped a mental switch in people's heads that said "hey I'm a Rockstar" and they decided they were having the time of their life, pressing buttons at the correct time as dots float down the screen.

The clearest example we got was our "Word Invaders" screen - which was nothing more then a word translation game where we gave you a rocket ship instead of a mouse cursor to pick the matching words. People love the game, even though it's the exact same mechanic as clicking on a word, just dressed up with some visuals and animation.

Building a base of knowledge:

Confident that we had something people would at least try - our next step was to switch from "Hunch-based"-knowledge to "Numbers-based"-knowledge. The advantage is that the latter can be done more easily remotely and you don't have to rely just on your gut. The disadvantage is that you need to get your numbers from somewhere and that takes some traffic and some technology.

Using a lot of the features we had already built into our Webiva CMS platform we put together a system designed to take in as much data as possible and make it as easy as possible to update the games based on that data.

The first thing we did was put together a quick infrastructure on the back end to input information for the games - instead of doing anything to fancy for inputting the games, we mostly used textarea's as big input fields and parsed the text in there to turn it into the words and phrases needed for the games. That (and using Webiva) saved us a lot of time building an Admin interface that let our non-technical partners build up the games.

The second thing we did was record every piece of user data we could. Yup that's right - everyone who visits the site is a guinea pig. We watch you learn and learn from your learning. Every time someone plays a game, or skips a game, or scores 100% on a game - we track it. This allows to very easily see where people are getting hung up and giving up. We also ask users to fill out a quick survey after playing - giving us some insight into how user recorded data correlates with the user's experience.

This gave us a lot of actionable data that we were able to quickly turn around and use to enhance the site. Some things we've learned: Starting people with a game rather than dropping them into straight Dialog boosts completion percentages dramatically. Swapping a very basic "Listen and click on the right word" game with the current game called "Balloon words" similarly gave us a big uptick. Making sure we don't repeat the same game twice in a row - also important.

Paying it backwards

In order to get data from peole playing the games, however, we needed people actully playing our games and there's only so many times we can force friends to play. Luckily there's an easy way to find beta testers even if you have no PR or press - you just have to pay for them for visit your site using PPC. Google Adwords is probably one of the greatest tools ever for a lean startup. It let's you find out:

1. How many people are interested in what you're doing (based on common search terms and keywords)
2. What words and phrases get people to care (using the detailed results on which keyword phrases people are clicking on)
3. What segments of what your doing (in our cases what languages) people care about the most.

We're paying $30/day and getting enough data that we can reach statistically valid conclusions when we try stuff out on site, at the same time learning about our target audience based on the performance of our ads.

A,B,C...

We've had good success so far optimizing the pieces of our site to boost site interaction. One of our next steps is to add in support for A/B testing the various games - all while tying back to some basic numbers like "% correct" will let us see exactly how to step the difficulty to maximize user learning and retention - information that most people teaching languages would never be able to get without explicit questioning and surveying (ain't the internet grand?)

That's how we're keeping it lean down at G4L - try our French and German Language Demos  - Spanish and Italian are on the way (this post inspired by the Lean Startup Bundle for the Lean Startup Challenge)

Posted Friday, Mar 18 2011 06:33 PM by Pascal Rettig

3D in the Browser: WebGL Presentation

With all the new releasing coming out - I thought it was a good time for a presentation on WebGL - below are the slides I presented to the Boston HTML5 Game Development Meetup on March 16. I also wrote a post on the state of 3D in Browsers on BostInnovation: 3D in the Browser: It's Go Time.




Posted Thursday, Mar 17 2011 01:20 PM by Pascal Rettig | Development, HTML5

PCI Compliance on Amazon's AWS

UPDATE: As  Spencer noted in the comment below, you can now configure ELB to generate PCI-compliant SSL proxying.
 
PCI Compliance, despite it's very important goals of safeguarding customer data, unfortunately right now exists primarily as a way for the processing companies to cover their butts. This weakness comes due to the fact that the bulk of the requirements can be fulfilled for small merchants by filling out the appropriate Self-Assessment Questionnaire (SAQ).

This is a little bit like asking high-school students to grade themselves on a test without giving them the answer key. There's the obvious problem of the students lying, but there's a further problem of them not knowing what the correct answer is. The terminology on the SAQ is not necessarily transparent.

To add insult to injury, most acquiring banks (the people who should receive the SAQ) aren't asking for it, simply because the number of vendors in the country processing payments far outstrips the capability of the card companies to check-up on them. Again, at the lowest levels PCI Compliance seems to exist primarily as a way to card companies to have their rumps properly protected in the event of a data breech. They get to levy fines and say "But they told use they were compliant," without springing for (the admittedly large cost of) an actual verification process.

There is, however, one part of level 4 compliance that has some value - and that's the need to pass a quarterly security scan from a Approved PCI compliance Scanning Vendor. This scan, even while it's not perfect at least provides a minimum baseline of safeguards a company needs to fulfill before it can reach compliance. Make sure you've applied the latest security patches and aren't running ancient software. That sort of thing.

Amazon recently reached level 1 compliance as a service vendor, meaning it's possible to run any size cardholder data environment on Amazon's cloud without being in violation. Unfortunately most Rails hosting companies, even those built on Amazon's AWS (like Engineyard and Heroku) don't seem to offer compliance or offer it at a significant premium.

What this means is that if you want to be compliant on the AWS cloud you either need to not take in any credit card information anywhere in your site (offsite pages, such as those provided by Braintree or Chargify are a great option) or you need to deploy your infrastructure directly onto EC2 yourself.

The good news is that the baseline infrastructure needed to pass the Automated security scan, provided you App doesn't have any holes is pretty straightforward.

There were only two notable things we had to do to pass the ASV:

1. Deploy the (as of this writing) latest version of Ubuntu - 10.10 Maverick. We deploy from the excellent alestic images. You need Apache version 2.2.16 or later to be compliant. 2.2.17 is preferred as 2.2.16 will still show up with a couple of notices (primarily related to expat vulnerabilities) but those won't affect your compliance. You could also probably find a backport of apache2 to the 10.04 LTS or compile your own. I don't know have any details on other distributions.

2A. Set up your SSL certificate directly on your instances Apache. You'll also need to disable weak ciphers and turn off SSLv2 by adding the following to your host configuration:

   SSLCipherSuite HIGH:MEDIUM:!ADH
   SSLProtocol all -SSLv2

As nice as Elastic Load Balancers support for SSL is - it unfortunately (as of right now) can't be configured in this way. Support in the API may show up at some point, see this topic on aws forums for more details. If your using ELB, you'll have to forward port 443 to your instances via TCP - which means you can't use any of the session stickiness options normally offers for HTTP connections.
A blog article on Zen One has some more details on the SSL issue as well as ways to test your configuration.
2B. (Or a Better solution) Ask amazon to configure a ELB with weak ciphers turned off. An Amazon rep we contacted has stated that they can modify anexisting load balancer to make it compliant - the advantage of this is that using Option 2A provides some problems with tracking the IP Addresses of incoming requests - something that is very important for fraud monitoring. We had to sign up for a support contract to open up a ticket to make this happen. This option also makes it possible to turn on session stickiness if that's something your app needs.
Next you need to actually run the scan - we used HackerGuardian from Comodo which gives you the first scans free. It's $250/year after that for 4 quarterly scans. They also have a SAQ Wizard to help you go through the steps necessary for compliance. The SAQ is a timesink and pain in the butt but it's not unmanageable.

And with that, you'll be good to go. You'll just need to find some people who actually want to pay you (but that's the easy part, right?)

Posted Saturday, Mar 12 2011 10:33 AM by Pascal Rettig | Business, Cloud, Development