This weekend (March 2-4, 2012), I competed in the Boise State University Appathon. This is a 48 hour competitive coding contest, wherein teams are tasked to create either a web app or a mobile app that has some relation to student life. Our team chose to create an alternative to Blackboard (which is the LMS that is used by BSU). The general feeling that I’ve gathered from students on campus is that Blackboard is a horrible kludgy tool that has no business being deployed in any production environments. I tend to agree with that statement.
Being that we only had 48 hours to build the application, we had to make some sacrifices. As such, we have not implemented the entire featureset of Blackboard. That said, I believe the feature set that we have implemented so far is enough of a starting point that the system could be deployed in production without much of a problem.
The challenges that I identified as part of this contest are as follows:
- Time constraints (there’s never enough time - this is not something unique to this contest)
- Team experience (I’ve been using Drupal for over three years now, but the other three people on my team had never touched Drupal before. I anticipated spending a large portion of the time in the competition getting people up to speed with Drupal concepts)
- Standing out as a unique app (While having an alternative to Blackboard is certainly appealing, there’s nothing that particularly sets that apart from other apps in the competition)
At first, we thought about building this app with Drupal 7. After looking into it a little bit, we decided that building a Spaces + Features + OG project in Drupal 7 is probably not a good idea at this point, mostly due to the fact that Spaces is not quite ready for Drupal 7 yet (to be fair, it does have a -dev release, but I didn’t feel comfortable relying on that for a competition with such tight time constraints). I decided that Open Atrium would be a good starting point for the application. This saved a lot of work in configuring OG, Spaces, etc.
A lot of time was spent with the String Overrides module. This was a quick and easy way for the other team members to jump in and start contributing to the project - String Overrides are pretty easy to explain (for the most part). This also served as a good way to introduce the Drupal translation system, and how the strings that are on the page aren’t necessarily the strings that have to be overridden (for instance, if the strings have replacement patterns inside). It didn’t take long for them to start digging through the source and finding the correct strings to substitute.