Saturday, April 20, 2013

HabitMaster Progress

This past week or so I've been implementing my previously-mentioned Habit Master design.

So far, things are going slowly but smoothly. I decided to divide my design into three apps: habits, users, and rewards. I first defined the habit and schedule models, some unit tests for them, and got them setup for admin view access. I also defined a User model before I realized it would be a much better idea to reuse Django's existing auth system for that. I still have a users app as a good place to put the views and page templates associated with account creation, login, and logout. I learned more about how templates work, so I have a base page template I'm inheriting from. I've also sorted out how static files work for things like style sheets and html5shiv.js. I'll eventually get Twitter Bootstrap into that mix too, but I'm focusing on functionality first.

There have been no major obstacles or bugs so far (knock wood). It's just been slow due to the general learning curve. Though I feel like I had a comfortable conceptual overview thanks to earlier exercises this semester, I still had to skim through the tutorial again as I completed each step for this project. I've also been diving deeper into the Django documentation for things like the auth system, view decorators (a bit like Java annotations), and request object details. I think Django could have provided more built-in help with my login form, but I haven't dug into that yet. Overall, I still like Django and its documentation.

I've been reading the HTML 5 spec to pick up some of the many new tags and throw them into the mix too.

There have also been a few toolchain improvements along the way. For example, I learned that git add . doesn't remove deleted files from the repository. To handle this, I learned more about git add -u, which will update all modified and deleted files but not stage any new additions, and git add -A, which will properly stage all changes. I've also been improving my virtualbox linux environment. For example, I found that KDE's Kate editor does allow to keyboard binding customization after all: you just have to go to Settings -> Configure Shortcuts... instead of Settings -> Configure Kate... to find them.

Hopefully things continue to go well. It doesn't seem like I have much to show at this point, but it feels like I've touched all the major parts at this point--apps, settings, models, tests, views, templates, urls, static files, and deploying to Heroku--so the rest should hopefully just be fleshing out more of the same. The next two or three weeks will tell.

Saturday, April 6, 2013

HabitMaster: Gamified Habit Formation

I'm starting on a new web-based gamification project. The current design is on GitHub.

This design has been evolving from its original broad concept. Some recent design additions include:

  • Users can now record notes regarding each task completion, or even if they did not complete the task for a given day.
  • Users can specify degrees of completion (green for "wholehearted" or yellow for "halfhearted"). However, to avoid discouraging those just starting out, this will be an advanced feature that is unlocked only once a habit has been firmly established.
  • Social features have been given a bit more consideration, though they will still probably not be implemented as part of version 1.0.
  • Fleshed out a number of specific details about the interface and flow between screens, including three new UI mockups.

Version 1.0 will include only the core features. I could evaluate the effectiveness of these gamification features by creating a second version with them stripped out. Specifically, this would omit the mechanics of streak tracking, leveling up a habit, badges, milestones, 1UPs, and social sharing. This would leave only the ability to enter habits, check them off each day, and review their history. I could then compare user adoption of the two systems: would users use the system longer and more frequently, have more successful habit formations, and enjoy the process more with these extra gamification features?

I'm looking forward to starting the implementation next week and learning some Django from scratch.

Makahiki Widget Development

My exploration of the Makahiki platform continued this week. I tried my hand at adding a few new widgets that could be inserted into a different pages. (Apologies to any general readers: this will be a very Makahiki-specific post.)

I started by following the Hello World tutorial. This was fairly painless and gave a nice overview of the files and functions that comprise a widget.

Next, I built a Group Scoreboard widget. At this point I wished for a bit more of a high-level overview of how widgets should work. I wasn't sure where the best place would be to add new data-gathering code: within the template HTML page, within the related, or in the corresponding manager library. I quickly learned that code within a Django template doesn't seem to handle any parentheses or parameters, so that left or the manager classes. I ended up working with both of these.

Groups are closely related to teams, so there was a fair amount of existing code to review and cannibalize. But, as with any complex system, it is hard to quickly build a mental map from the bottom-up like this. I felt a bit like I was redecorating while stumbling around in a dark room.

I got my Group Scoreboard together, though. I also built two Group Resource Use widgets. This proved a little trickier since it involved "subclassing" a widget. I also initially missed the INSTALLED_COMMON_WIDGET_APPS setting in, so I couldn't figure out why my common template file couldn't be found while resource_goal's could be. Also, I made a few errors that prevented the server from starting, and so I spent a while trying to debug single-line error messages such as "Error: cannot import name Team". I learned about this command:

  ./ shell --traceback

which provides a full stack trace on an error. This was invaluable for debugging.

By this point, I was running short on time. I skipped making a Group Prize widget and started on a couple group-related Status page widgets. I spent an hour or so trying to decide how best to gather the group data from the team scoring/ranking system that is spread between score_mgr and team_mgr. I started toying with a plan to filter the team data to include only those in one group. As I neared the point to start testing it, I realized I didn't know exactly how the existing score widgets were placed on the Status page.

Specifically, I found the two templates (team_point.html and team_participation.html) that I wanted to copy in the widgets/status/score folder. However, simply adding a new group_point.html template in the same place didn't auto-magically show up. There is also no status.score widget registered through the Makahiki interface. Instead, these templates appear to be controlled indirectly through a separate scoreboard app. Looking through scoreboard's template was a bit of a mystery, however, since it makes no explicit reference back to the status.score templates.

The listed Makahiki widgets (front right) and corresponding file structure (back left).

At this point, it was time to move on from this project to bigger and better things. Here is a shot of my successful widgets currently on the Profile page:

And these are available within Makahiki to be added to any page: