Hacking Away at a Hackathon

Robert Cooper
Osedea
Published in
7 min readMar 28, 2018

This past weekend me and four other of my co-workers participated at the 2nd annual Radio Canada Hackathon in Montreal, Canada. The goal of the hackathon was to build an Artificial Intelligence (AI) solution that could be used for the media industry.

This was my first hackathon, but luckily most of our team had experience at other hackathons and so we had a good overall sense of what to expect. That being said, we took away a lot of valuable lessons from the experience.

There were around 30 teams comprised of 4–5 people each that presented a wide range of AI solutions. Some examples include:

  • An application that analyzes news headlines to predict the virality of the news article
  • A chrome extension that allows users to select an overall “tone” for a news article where the AI would strategically replace certain words to match the selected “tone”
  • A tool that analyzes words to see if the public sentiment associated with those words is positive or negative

Our Solution

Our team came up with a web app that allows users to create voice applications for the Google Assistant and Amazon Alexa through a web interface. The idea behind it is that an easy-to-use web interface to create these voice applications would allow people with non-technical skills to create their own applications. This web app could be used by media companies to help make their content available through these virtual assistants and therefore more accessible to the public.

We had done a bit of preliminary research prior to the hackathon to verify the feasibility of the project. We found an open source tool, Jovo Tech, that allows for the creation and deployment of voice apps to both virtual assistant platforms (Google and Amazon). The open source tool was very programming heavy and did not provide any sort of frontend UI to interact with. This gave us the confidence to pursue our project idea since we could bootstrap our project with the open source tool, which would help to the amount of work involved on our side of things. Huge shoutout to the contributors to Jovo Tech for both creating the tool as well as answering our questions on their community Slack channel.

We leveraged Jovo Tech, which is an open source tool for creating cross platform voice applications

Building The App

Aside from our preliminary research on building cross platform voice apps and testing out the creation of Google and Amazon voice apps, the real work started at around 7 PM on Friday at the Hackathon. We divided up responsibilities and we checked in with each other every hour or so to make sure things were progressing well and to address any issues we encountered.

One thing I learned quickly is that there is no time to dwell on an issue. If you encounter a hurdle that you cannot resolve within 10 minutes, you ask someone else for help. If there is an issue that has the potential to derail the entire project, you huddle together and figure out a way to course correct. One such issue was when we discovered that the Amazon Alexa would not work in French, which is the language of all the Radio Canada news and the language in which we had to present our prototype. The workaround was that we had to abandon the Alexa voice app for the purpose of the presentation and only present with the Google Assistant.

Team photoshoot at the hackathon where we had coincidentally all worn the same shirt

The result of this accelerated problem solving was that it helped shift the way I approach problems. I have a bad habit of trying to stick to a game plan when working on a project, which has probably hindered my progress on many occasions. I often resist exploring alternative solutions that would get the job done faster. A tangible example of this would be trying to use a high performing, but hard to implement programming library/tool, rather than an easy-to-implement tools that is good enough to get the job done. Of course having a high performing application is great, but if you have deadlines to meet, you do have to make certain tradeoffs.

We spent Friday night working at the hackathon headquarters, but we opted to spend all of Saturday at our office. Being at the office gave us more space and allowed us to use our external monitors to be a bit more productive while working on our laptops. There was very little downtime during the duration of the hackathon and everyone was extremely focused the entire time we were together. We took breaks to eat and we took a group walk outside, but apart from that, we were hard at work on our computers.

When Sunday came around, we had around 4 hours left to prepare for our prototype presentation. Our focus was on the web interface of the application, testing out the Google Assistant for our demo, and creating the presentation video/slides. We kept having to cut out some of our desired UI features since we were running out of time. We were also being graded on web accessibility so we were furiously adding alt attributes to images, trying to use the proper semantic HTML elements, and implementing other accessibility features. We weren’t close to being WCAG 2.0 compliant, but we did what we could with the time we had.

In summary, this is the breakdown of the time we spent building our application:

Friday: 7 PM — 1 AM (6 hours)
Saturday: 9 AM — 3 AM (18 hours)
Sunday: 9 AM — 1 PM (4hours)

Needless to say, we were tired when it was all over.

The Presentation

We ended up creating our app which we called Scr!pt. You can view the website at scriptapp.ca, but you can’t create voice commands there yourself. The thing is, the app isn’t fully functional (yet), but we know that all the functionality of the app is possible. In fact, we have almost all of the code required to make the application work with the web interface, but we just didn’t have enough time to make the final connections between all the moving pieces of the application. If we had another full day to work on the app, I’m sure we could have the web interface working as intended.

That being said, we were able to put together a very strong presentation. Our app had a very good-looking landing page and an embedded Youtube video demonstrating how the application works. We also demoed a custom voice app with the Google Home during the presentation. The voice application wasn’t actually created through our web interface since, like I said, all the pieces weren’t plugged into the web UI, but we presented the app as though it was generated using our app.

The voice app demo gave the user the recent news articles from the Radio Canada API and we also added in a bit of humour. The last part of the voice app demo with the Google Home went something like this:

User: What was the result of last night’s hockey game?

Google Assistant: Do you think the Montreal Canadians won?

User: I think so.

Google Assistant: Keep dreaming! The Montreal Canadians lost again with a score of 6 — 4.

This got a few laughs and ended our presentation on a good note. Afterwards the judges asked us a couple questions, with one of them being: “Did you actually start building your prototype during the duration of the Hackathon”. Apparently the judge had a hard time believing that we built our solution entirely within the duration of the hackathon (which was less than 48 hours)! In fact, we heard afterwards that a lot of the audience members also did not believe that we started our project during the hackathon, but rather that we started building our app ahead of time! I’m sure if everyone knew the true capabilities of our application (i.e. that it wasn’t fully functional), they wouldn’t be as skeptical about when we started building our solution.

You can view our prototype presentation below (note: it’s in french).

View our presentation (starts at 2:10:44)

After all the prototype presentations were completed, the judges took around an hour to make their decisions. Our team was asked to meet the judges in their “decision room” during their deliberations because they wanted to verify the creation date of our project’s Github repositories along with the functionality of our application. We showed them that we had all the required code in place to handle the app’s core functionality, but we did not have enough time to make the web interface work as intended.

The Result

We ended up winning 3rd place overall for our solution. Sure winning a prize is nice, but I think the real value came from the experience we gained working outside of our comfort zone and working on cool new technologies. Although there were definitely some stressful moments due to the time constraints of the hackathon, everyone was very supportive and encouraging towards one another and we all enjoyed ourselves. I’m extremely proud of the hard work and dedication everyone showed and very pleased with the end result. I’m already looking forward to my next hackathon!

All smiles after a weekend of hacking

--

--