Testing The Makahiki Administration System

This week I tested the Makahiki challenge administration system. For the most part, the instructions for creating and configuring challenges were clear and understandable. I experienced only three problems: a problem with user account passwords, mistakes I made in assigning dependencies, and a difficulty in coming up with new designs for events outside the scope of the default actions already available in the library.

Non-reproducible passwords bug

At first, I was unable to log in with either of the non-admin accounts I had created, playerA (password: AAAAAAAA) and playerB (password: BBBBBBBB). I am not sure what caused this bug, and later users I had created did not have this problem. Using the “Log in as user” option while logged in as administrator took me to an error page, and I was unable to log in or log out in that browser (Firefox 19.0.2). Opening a new browser (Google Chrome 25.0.1364.172 m) allowed me to log in normally.

An error page.

I was redirected to this page after using the “log on as user” option.

I assume this bug had something to do with browser cookies, but I was unable to reproduce it.

Difficulties of Challenge Design

When designing new activities for the challenge, my greatest problem was coming up with original activities. As a testament to the breadth of the default activities that most obvious commitments and events, such as bottle recycling, use of natural light, and using public transportation are already covered.

The Makahiki markup system which sets the conditions for unlocking challenges is simple to me as a computer science student, since it consists of boolean statements based on whether or not activities are completed. Though I was able to figure it out on my own, I think the “Design The Smart Grid Game” section should provide a link to the “Supported Predicates” article so the user knows where to find this information. Example predicates are shown in the article, but the predicate system is not explained in that section of the documentation.

Level 4 test challenges.

Above: These challenges were set to unlock such that completing research-apps unlocked the rest of the board.

One possible improvement to the administrative interface would be some kind of dependency graph visualizer. Though it is probably not needed by administrators who rely mostly on the default challenges, it may be useful for challenges with a higher degree of customization. However, I am not sure how feasible it is to implement this in Django.

Difficulties of Challenge Management

I have no issues with the challenge management system. One useful feature is the ability to approve challenge submissions in batches. With the exception of variable-point-value challenges, this seems like it would be very helpful for challenges with large numbers of participants. Badges are awarded automatically, and the system keeps track of who is eligible for points-based, energy-based, and raffle prizes. It seems as if actually managing the competition once all activities and prizes have been set up is much easier than the process of setting up all of these items and their dependencies.


As a whole, the hardest part of Makahiki challenge design is probably keeping track of dependencies between different levels of activities and making sure that activities are unlocked in the correct order. Creating individual activities is simple, though the predicate syntax which Makahiki uses to determine conditionals may be difficult to understand for some users. Managing the competition was fairly simple as long as the conditionals were correctly set during the challenge design phase.