As shown by the readings, ICS 314 student teams have a tradition of winning most or all of the awards they are eligible for. However, to win, you must use the time in the HACC efficiently. Some advice:
From prior experience with all of the HACCs, I know that many teams will take almost a week to get productive. If your team gets productive the day that the HACC starts, you’ve just given yourselves 33% more time to work on the project.
HACC allows you to choose any technology stack, but you should seriously consider using the class tech stack for HACC. If you do, you can continue to work on your HACC project as your final project for ICS 314. This is a great strategy, because it means you’ll have a substantially better ICS 314 final project (which will improve your grade) and (more importantly) you’ll have a much more sophisticated project at the end of the semester to include in your professional portfolio.
In order for you to use your HACC project as your final project, you must do a couple of things:
Have at least three people from your section of ICS 314 on your project. That is the minimum team size for the 314 final project, and all members must come from the same section. (You are welcome to participate in HACC as part of a team with less (or no) members from 314. It just makes it harder to use the project for your final project.)
Use React, Bootstrap, and Meteor as your technology stack. Your final project must use the class tech stack, so your HACC project must use it as well. This is actually a good move, strategically, for the HACC regardless of whether you decide to continue working on your HACC Project for your final project. Learning a new tech stack for the HACC means you have less time to develop innovative features.
Some people participate in two or three HACC teams simultaneously. After seeing the results, I don’t recommend it, because during the “crunch time” (i.e. the last week) you’ll have to split your time between multiple projects just when each project (and team) is hoping for your undivided attention. I think it’s better to put all your eggs in one basket and create the best possible single submission.
Here’s the video from the 2016 HACC winning team:
Wow. There’s just no doubt about it: this video is stunning and head-and-shoulders above every other team’s video submission. The video is not just technically impressive; it tells a story about the project. The actual Ohai application only implements a few static HTML page mockups, but the team did a superb job of communicating stakeholder requirements.
But you don’t have to go all in on Adobe After Effects to make a good video. Here’s the video from the 2017 HACC winning team:
No special effects, but plenty of drama (the “actor” in the video ran into the Judging room right as the video stopped playing!)
Finding someone with video experience can be tricky, but the UH Academy for Creative Media, Department of Communications, and even the Lava Lab can be source of students with this skill set.
Most of the competitive submissions implemented a CRUD application that could be displayed on a smart phone. Fortunately, every Meteor app built using Semantic UI will display well on a smart phone, satisfying the “mobile app” criteria.
Since all the competitive submissions implement a CRUD app, if you want to win, you need some “special sauce”, as noted next.
The HACC provides you with enough time to develop your app beyond CRUD. For example, my 2016 HACC submission, Kipa extends a mobile CRUD app for OCCC scheduling with three special sauces: (1) reactivity, (2) text messaging for communication, and (3) an extensible constraint system.
Fortunately, the ICS degree program provides a wealth of material for you to apply to your HACC project, including: security, recommendation engines, advanced visualizations, concurrent programming, machine learning, robotics, game mechanics, medical informatics, etc. You might even consider using Raspberry PI or Arduino boards to craft an Internet of Things solution.
The judges will not view “usability”, “native app”, or “cool buttons” as “special sauce”. Basically everyone is going to claim their application is highly usable. If you want to win, your app needs to do something interesting and domain-relevant. Feel free to discuss your ideas for special sauce with me.
You might be tempted to build a native mobile app using something like Flutter, React Native, or Ionic. The problem is deployment: getting them into the Apple and Android stores is difficult and costs money.
If you want to get something that actually works and can be deployed to real users within three weeks, your best bet is to create a responsive web app that can be deployed and support real users just by providing them with the URL. With Meteor, you can deploy your application to the cloud and redeploy it with improvements in just minutes.
Three weeks is enough time to build an initial version of your application and obtain user feedback. Depending up the organization and application topic, you could release your initial version after two weeks, and get feedback from dozens of users by the end of the hackathon period.
It’s hard to be a judge for HACC: they have very little time to evaluate the submissions, and there are always a lot of final submissions to evaluate. I learned from veteran hackathon participants about “strategies” to make the submission more superficially appealing to judges. My advice: don’t play the “game”; just build the best possible system that you can in the time you’ve been given.