A few months have passed since the 2018 ECCE App Challenge was underway. Having now completed two App Challenges, I want to share my experience to tell you about what it’s like and also share some useful tips I learned along the way.
For those who don’t know, the ECCE App Challenge is a week-long hackathon-style competition, where teams of students must create an app, promotional video, and a well-documented GitHub repository for a given topic. No small task! This year, I was part of Team Marauders mApp with Michele Tsang and Tasos Dardas. Overall, we came in third, which is a significant achievement having not personally placed in the top 3 last year. Unlike previous years, the provided topic was completely open-ended. We could make an app on any important topic that we chose. This was both a blessing and a curse – a blessing in that we had complete freedom in choosing a topic, and a curse in that having such freedom made narrowing down a specific topic challenging. As any participant can tell you, coming up with a topic that can be realistically turned into an app within a week is potentially the most difficult part of the challenge. So much rides on the decision because, after all, if your topic doesn’t yield a useful app then you’re likely not going to do well in the challenge. Some teams even find that their topic is too challenging to implement several days into the competition, forcing them to simplify it greatly, or scrap the idea entirely, resulting in a lot of lost progress. Knowing how to adapt is key, since your initial idea will more than likely hit several roadblocks along the way. For example, in one component of our app we wanted to allow users to draw custom areas that the app would then report the solar potential for. We found that the initial study area we wanted to use did not have any solar open-data. Creating our own would have been too time-intensive, so we had to change our study area to Calgary, which did have the data. Even then, we had to perform 9 hours of analysis on that data just to make it workable for our purpose (more info on that in Michele’s post here). In short, coming up with a useful-yet-doable concept and knowing how to adapt to roadblocks along the way is one of the most important skills you can have for success in the App Challenge.
My primary role in the challenge was creating different media elements – custom icons, images, and the promotional video. I noticed a trend in previous challenges that the winning groups had the highest quality videos. My goal was to make the most professional, high-quality video yet. Having basically only used Windows Movie Maker in the past, I purchased a student license of Adobe Creative Cloud for $20. This gives you access to Adobe Premiere, which is a professional-level video editing software. Having never used this software before the challenge, I had to learn how to use it very quickly. I ended up using YouTube tutorials to teach myself the software as a small personal challenge. I also learned to use Photoshop and Illustrator to create images used for the challenge, which once again have countless tutorials available online. I made use of royalty-free HD stock footage, music, and images to give our video a documentary feel. I also had to learn about recording high-quality audio with a great free program called Audacity. Despite having never touched any of the media software I used before the challenge, I was able to create a 1080p HD, 60 frames-per-second video with high quality voice-over. I’m really proud of this accomplishment, and I would love to see video quality continue to improve in future challenges
Due to time-constraints, the app demo portion of our video is significantly lower quality than the first half. You can even see in the corner of the video that the time of recording was 2 hours prior to the deadline. The reason for this is that our app was running into problems and our lead programmer had spent a couple all nighters to get it working. We did not have a functioning demo until 2 hours before the deadline, so I was under significant pressure to get a decent demo together in a very short period of time. The main problem with our demo is that my voice-over is extremely disjointed. Without knowing, you would probably think I had no idea what I was talking about, as I was stuttering about everything happening on screen. The reality is that my commentary was happening in real-time without any type of script prepared, after working 9 hours already that day. The thing about live commentary is that if you trip over your words once and get flustered, then you have to start over. As you can imagine, this happened a lot and I had to end up splicing different audio and video tracks together to make something that made sense. This is coupled with the fact that my screen recording software was causing significant slowdown on the demo computer which also ran on Linux, an operating system I had never used before. I don’t think anyone could have done a great job under those circumstances, but still I regret not having some type of script written, especially since every other part of the video is scripted post-commentary, which is way more relaxed.
I also want to give some general tips for success. First, keep your app simple. We tried to make an app that had a few different components, some very novel and others that were straightforward. Some components ended up working better than others, and if we had focused on making just one really well then we could have potentially won. If your group is composed of only 1 experienced programmer like ours, then having a more focused app also relieves a lot of stress on that individual. As I said before, our programmer stayed up all night a couple of times to make sure we had a working final product. Second, don’t use jargon. In our app, we made the mistake of constantly referring to “DAs” or Dissemination Areas. These are standard Statistics Canada units of geography that we all know, but to the average person it has no meaning. Do not be afraid to slightly simplify your language, even if it is technically incorrect, to improve user experience. Last but not least, make use of the Esri technology that is available to you. We ended up taking a different approach with our app by writing it partially in R code (which is typically used for statistics, but also has app capabilities through a package called Shiny), and Leaflet. Our app was not hosted using the Esri Web AppBuilder for ArcGIS, which means we had to create almost everything from scratch. In retrospect, we could have saved a lot of time using more of the Esri framework and leveraged some of the pre-made tools. Also, we could have leveraged Esri’s Calcite Maps Bootstrap theme to improve our UI. The winning team of the competition used this, and it ended up looking very attractive.
The ECCE App Challenge is a great opportunity for students to dive into learning how to make attractive and useful web apps using modern approaches. Even if you don’t know how to write code, I recommend participating because you will learn a ton! I am very excited to have achieved third place this year and I can’t wait to go for gold again next year. 2018’s entries are some of the most ambitious and well-executed apps that I have seen to come out of the App Challenge thus far, so our work is definitely going to be cut out for us.
To see our complete submission for the 2018 app challenge, visit https://esricanada-ce.github.io/appchallenge/2018/teams/mac/Marauders_mApp/