Mobilizing DrupalCon Chicago
by Larry Garfield
With the dust settled and results tallied, we finally have time to look back on DrupalCon Chicago and all the work that went into it. And much work there was! The whole team did an amazing job, and I'm proud to have been a part of it.
One place in particular that we broke new ground, at least for us, was the DrupalCon Chicago mobile app. Chicago was not the first DrupalCon to have a mobile app, but it was the first to have a fully cross-platform application for both of the dominant mobile platforms, iOS and Android. With the immense surge in popularity of Android in the past year and the continued strength of iOS supporting only a single mobile OS would not have been an option.
At Palantir, we've discussed working on mobile apps on and off for some time but never had a client who was sufficiently interested in one. The DrupalCon Chicago leads, though, were sufficiently interested (and also happened to be my bosses). At the same time, Pat Teglia had recently joined the Palantir team and had been experimenting with mobile development on his own. Jen Simmons, also a new Palantiri, was eager to try her hand at designing for a new environment. And although it's been a while, I used to be a mobile developer back when Palm OS 4 was still considered cool. (I know, back in the dark ages.) It was an ideal combination, and while the end result wasn't everything we hoped for it was a qualified success.
Building the app
We knew from the beginning that in order to be successful, we would need to integrate the app with the DrupalCon website. Most importantly, we wanted to be able to pull down session and presenter content from the site on the fly so that attendees always had the most up to date info (especially regarding schedule changes). Although other sites have built Titanium-based companion apps before, none of them have resulted in a reusable Drupal-centric library. Our first task, therefore, was to try and build one that we could use and then release.
That turned out to be a double-edged sword. On the one hand, it resulted in a fair bit of overly-generic code that we didn't truly need for this app and didn't even end up using. On the other, some of that extra flexibility ended up saving our bacon later on when we needed to work around some bug in Titanium or inconsistency in Drupal's output. Most notably, it included a partial port of Drupal 7's database layer to Titanium in order to support the dynamic queries we needed to handle.
Originally we intended to use the Services module to authenticate users against the site and then download complete session nodes to the app. We soon realized, however, that not only would that be inefficient (there were a lot of session nodes) it wouldn't give us complete data: Much of the data about a session was spread out across dependent Room or Time Slot nodes, as is quite common in a modern Drupal site. Instead, we dropped Services and switched to the Views Datasource module, which let us use Views to generate fully-filled-out pseudo-nodes that we could download as JSON in a single HTTP request. That had its own challenges, most notably inconsistent JSON structure and a misuse of Views' display plugins, but fortunately we were able to work around those thanks to the extra layers we had built into our library code.
In the end, we were able to allow the user to refresh their data at any time from the site with only a single HTTP request, and then slice and dice data however we needed to for display. We went through a couple of different iterations on the design before settling on the layout we shipped with, actually, and scaled back some portions after realizing that we wouldn't have time to build. Having all of our data on-demand with a clean way to rebuild and reindex it made it easy to vary the application as we evolved the design.
The other major feature we managed to sneak in at the last minute was the ability to review sessions direct from the phone. Given the importance of evaluations in helping future DrupalCons pick good presenters, we wanted to make that process as easy and painless as possible. Rather than duplicate functionality here, we simply directed the user to an embedded browser within the app that pointed to the evaluation form on the web site, complete with custom CSS to make those pages mobile friendly. We even managed to sneak some improvements into Bakery in order to streamline the login process. (To be more specific, the nice folks over at GVS did that for us.) While not as slick as we'd hoped, it was still faster than trying to authenticate via Services and then recreating all of the form functionality in the app.
Fun with stats
The week of the conference, we had approximately 2,000 downloads, which was about 2/3 of attendees. Most were from the USA, of course, but a few were scattered across Europe, Asia, and Australia. Titanium's embedded statistics reported that the app was started some 12,000 times, with an average of 6.5 sessions per user. Hopefully at least 10,000 of those were enjoyable experiences...
What we found most interesting, however, is the platform-specific stats. Not surprisingly, given a typical Drupal audience, iOS downloads outnumbered Android downloads 2 to 1, even though Android has a slight lead in the overall market. Android users, however, apparently used the app twice as much as their Apple-using counterparts. I cannot speculate as to why that is (although you're welcome to do so in the comments), but we found it fascinating.
Certainly one thing is clear: Future Drupal events that decide to go mobile cannot afford to ignore either platform. There are lots of mobile Drupalers, but they're rather heterogeneous as to their platform of choice.
The feedback we received on the mobile app, both in person and via the Apple App Store and Android Market, was overall very positive. The biggest complaint people had was the lack of a "my schedule" feature in the app. We actually considered that a good sign, as we had wanted to build that feature in. Why didn't we? Mostly we ran out of time, and only wanted to build it if we could do it right. By "right", we meant integrated with the session flagging on the DrupalCon site itself. We decided that it was better to not have two disconnected personal schedules so dropped that feature, but we'd love to see a future conference finish that off. (The Services integration needed is already partially there.)
Both platforms had their challenges, however. For Android, the available emulator is surprisingly slow. The process of compiling and testing the application on the Android emulator was far slower than with the iOS Simulator, which for a team used to instantaneous feedback from a Web script was a challenge. We frequently found ourselves doing primary development with the iOS Simulator and then testing periodically on the Android emulator, simply for time reasons. Whether that is due to Android, Titanium, or both we aren't sure.
For getting the code onto actual hardware, though, the process was reversed. Getting the app to debug on actual Android hardware was a simple matter of checking a few boxes on our phones. Getting it to run on iOS hardware, however, required many hours to figure out the keys and permission codes needed to authenticate our hardware for testing and debugging, due to the restrictions placed on the platform by Apple. (It also had the unfortunate side effect of wiping out George's progress in Cut the Rope.) As a result, we definitely recommend having dedicated hardware for testing and debugging with iOS, and setting it up at the beginning of the project.
At the same time, however, even just in the past four months the HTML5-based frameworks have improved and older, limited versions of both OSes have dropped off the market. The mobile market is still changing very rapidly, and by the time of our next mobile app an HTML5 framework may offer everything Titanium does, or at least enough of it for our needs, as well as being a development environment we're more used to. Depending on the client, we'll be evaluating both Titanium and HTML5-packaged apps again for our next mobile project. We might even consider native apps, but only if the client really does need only a single platform.
For now, the source code for the DrupalCon Chicago mobile app is publicly available under the GNU General Public License version 3. (Titanium is Apache 2 licensed and the Drupal DB port is GPLv2+ licensed, which means the app has to be GPLv3.) Hopefully it will prove useful on your next mobile project, or Palantir is available for further customizations and consultation. Let us know if you're interested.
We'll see everyone at DrupalCon London!