Hackathon in the key of mobile

We had pizza.  We had Doritos. We were coding up a storm after most of the office had gone home.  All of those details could only point to one thing: an Intelliware hackathon!

The mobile development world is a complex and quickly-evolving world, and it’s been important for us to ensure that we find time to practice, cross train, and try out various different tools and development kits that are important to the mobile space.  So when Marc suggested a hackathon event as a skills development exercise, we all saw it as a good chance to flex our learning muscles.

We did a bit of quick planning: there were nine members of the Mobile Centre of Excellence, including our officially-designated overhead, Bruno.  We decided to break up into four teams. In general, to get some of that cross-training goodness, we planned for each team to have one expert in the development area, and one novice.  For example, one team was planning to use HTML5; Craig is one of our strong HTML5 developers, so he was tapped to be the master on that team. Alex, on the other hand, wanted to grow his HTML5 skills to complement his native iOS skills, so Alex elected to be the student in the HTML5 team.

Three teams were pretty easy to establish:

  1. An iOS team — admittedly, we’ve got a lot of iOS skill in our group, as many of us have dipped our toes into that water.  Marc, one of the company’s first iOS developers, was our iOS master and he worked with student, Raul who has been HTML5 Dude for most of his time in Mobile.
  2. An Android team — Android is the platform that we’re built the fewest applications on, which is surprising given its market share. Nonetheless, Eagle (whose day-to-day mantra seems to be “everything’s better on Android”) was our master for the Android platform and Rom (iOS, Cordova and Worklight) wanted to grow his skills on that operating system.
  3. An HTML5 team — as I mentioned, Craig took the teaching duties on this team, and Alex was the HTML5 novice.  Since Craig has been using Meteor.js for the last few months, they decided to implement their HTML5 application using Meteor.

That seemed to cover three of the most common development options in the mobile world.  But we still had three people left to allocate.  We briefly considered BB10 as the third option, but opted instead to break our master/student paradigm for the fourth team, and try taking one of the MADP products out for a whirl. Of the four MADPs products that we like best for enterprise mobile development, the one I most wanted to take for a test spin was Appcelerator Titanium. We had more direct experience with the other three tools, but we’ve never been called upon to do a real project with Appcelerator. Thus, even though none of us could claim “master” status on Appcelerator, Bruno, Melo and I became the fourth team.

The constraints of the hackathon were chosen to impose a few hard requirements, while at the same time granting a certain amount of creative freedom.  Here they are:

  1. The hackathon would begin at noon on the Friday that we’d chosen.  No coding could start before then.
  2. We’d code for eight hours, and then present our completed apps for judging and ridicule.
  3. Each app was required to communicate with a server. (This also had the effect of requiring each team to build some kind of server).
  4. Each app needed to include these functions: login, a feature that would fetch a collection of data from the server, and a feature that would post data back to the server.
  5. The app also needed at list one “list of data” view, and some page navigation.
  6. The final presentation had to be demo-ed on a mobile device.
  7. The app needed to be “useful at the scene of the crime”.

And that was it.  I particularly liked the last rule: it was specific and unusual enough that we had to tailor our apps around that domain, and yet it was vague enough that we could let our imaginations go wild. We were also pretty clear on the idea that “useful at the scene of the crime” didn’t necessarily mean that the users were on the side of law enforcement, but I think most teams were apprehensive about the PR implications of designing a really good application for committing crimes. (Me, I had a great idea for an app to let professional assassins bid on and win contracts. Like eBay for contract killers! My teammates chose a different path. Also, I think they’ve been kind of avoiding me since then.)

All-in-all, the hackathon was a fun event. We all seemed to bring a certain amount of enthusiasm to the exercise and friendly competition seemed to bring out a certain amount of creativity.

How did it all go?  Really well, I think (Spoiler: our team won, but I’m sure that hasn’t biased my perception of events.)

Marc concedes that his team got off to a bit of a slow start.  Marc spent so many of the previous months writing proposals instead of writing code that his iOS skills got rusty, and that cost his team some time.  The iOS app was intended as an interview tool: interviewers could take notes, photos or video of an interview, and those things could be sent up to the server. He and Raul had a good rough outline of what they wanted to accomplish, but lost a lot of time in set-up, and really only demoed login and a collection view.

The Android team worked on an app that allowed users to submit reports of different kinds of incidents to the police. What’s more, they also decided to spruce up their app’s content by throwing together a quick web spider that fetched real police categorization and standard procedure material from the Toronto Police web site. (We briefly wondered if the police were going to contact us if they noticed the many, many requests we sent at their server as Rom tested out his data fetcher but so far, we haven’t heard a peep.)

Eagle was especially proud of the features that allowed the app to adapt to different types of devices, and when it came time to do the demo, he made sure to show it off on both a phone and a tablet device.  But those items came at the expense of some of the core requirements such as login and posting data.  The design of the app tended toward some bland grey tones, too.

The runner-up app came from the HTML5 team. Since Craig has been working with Meteor for the last little while, he brought that technology stack with him to build their “CSI” app.

Their app was a fingerprint analyzer.  The schtick was that a law enforcement official could photograph fingerprints at the crime scene, and those fingerprints would be sent to the server for analysis.  The server would then send the results of the fingerprint analysis to the device, including a photo and quick details of the matching suspect.



Now, okay, there was no real fingerprint matching, but that’s a detail of the server implementation — from the device side of things, the app was pretty slick.  One of the things that made it stand out, especially, was that it had a relatively attractive UI.  Craig and Alex made a point of slapping a nice background image on a welcome screen, and other screens had some nice CSS-ification going on.  One of the silly additions involved their “database” of criminals — they scraped some photos of Intelliware employees and added evil eyebrows to all the mobile developers.  The net result of all this was an app that lent itself to an effective and attractive demo, with some built-in yuks.

And I couldn’t help but reflect, then, that despite the number of times I’ve done demoes where I advised my audience that “the look and feel is only temporary; focus on the functionality, not the appearance”, I found myself unable to avoid favouring a demo that had more attractive screens and UIs.

On the Appcelerator team, we spent the last 45 minutes of our development time adding some graphics and color to our app, and once again, I think that helped us out.

The app, itself, was imagined as a tool for Medical Examiners — it’d give MEs information about crime scenes, and once on site, they could take photos and notes of the bodies in situ. Since I’m a big fan of giving things memorable names, I proposed “Quincy IWD” and the name mostly stuck.



Like the iOS team, we sketched out a quick screen flow, and used that to guide our development. We finished almost all the features we intended and still had time for some UI gloss.  And for the lulz, we also used an image of the Operation game on a key screen.  These things, coupled with the sob story we told about how none of us had really used Appcelerator for reals and we were all fumbling our way through the development using this new, exotic tool, led to the judges taking pity on us and giving us the winning prize.

But that’s not really honest because, truth is, we became quickly productive using Appcelerator. We exercised a number of features of Appcelerator Titanium. We styled things, we used cool features like maps, and we got quite a bit done.  The one area that  I’d favour having a better handle on, for any future Appcelerator project, would be layout strategies — we tended to using absolute positioning rules which I suspect aren’t the best for cross-device support.  For me, the opportunity to hunker down and really run Appcelerator through an almost-real-world development exercise made taking the time to have a Hackathon worthwhile.

And one of the things that Bruno pushed for (but which we didn’t get around to) was demoing the app on a second (very different) device. We demoed using an iPad mini, but since our code wasn’t iPad-specific, we should have been able to run the same code on an Android tablet. We didn’t end up doing that, but, yeah, it might have been a cool extra punch for our MADP demo.

It's only fair to share...
Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn