No Guts, No Badges

My preferred method of coding when I’m not quite sure what is going in can be summed up in five words: “Let’s see what this does!” This week I continued constructing the guts of badges system and it was definitely chock full of trial and error. I did a lot of writing, realizing that I actually needed another method, rewriting, realizing that I should really combine methods, rewriting again, realizing that I really wanted to return something else, and rewriting yet again.

However, I have emerged (mostly) victorious with relatively stable foundation for badges. You can now see which badges are unlocked (all the prerequisites are fulfilled) and recommended (the badge is unlocked or started, but not completed) for a user. Given a world, you can return which levels of which badges it could have earned based on its skills. I have also started work on giving badges to users once they upload a world. I did some preliminary testing by hand-manipulating fixtures (or fake data). Following a tip from Jordana, I plan on learning how to write functional tests and slowly adding them on an as needed basis. This way, when we are ready to release badges to the public, we will be able to rigorously test them.

Starting in the middle of the week, I took a break from the data manipulation to work on the visualization. (This has also helped me to refine my logic and really think about what methods I have and what I want my methods to do).

I added a badges index page to the website. If the user is logged in, it displays the badges that the user has earned and indicates which ones are unlocked.  Eventually, these badges will have rings around them indicating the remixes and they will be displayed in a tree format that shows which badges feed into which.


When I wrote the recommendation system for badges, I began to think a little bit about how we might refine the recommendation system for badges. For the visualization of badges, you don’t need anything more than a simple check to see if the criteria are fulfilled and that it isn’t complete. This means that at any given time, a user could have a lot of recommended badges. This is good. It offers our users flexibility in their choices.

On the other hand, there are a lot of factors that we could emphasize in the recommendation system. These are (but are not limited to): Has the user started but not finished the badge? Has she remixed the next level? Would earning this badge be beneficial to another badge? Has a person she is  following earned this badge?

I’m not quite sure how this refined recommendation system would manifest itself. (Would it be incorporated into magic sort? Would there be a “suggested badge” on the index page?) Obviously, just because you can do something, doesn’t mean that you should. Furthermore, even if we did decide to go this route, a refined recommendation system is low on the to-write list. However, it is interesting to think about.