krawaller

During the past month, we've been hard at work on the official application for the metal band Tristania, a project now nearing completion. This process has given me much food for thought, and a new love of my life - Yahoo's YQL tool!

Band app content

As the specification for the project was rather vague (us: "do you want an iPhone app?", Tristania: "yes please!"), the first step was to figure out what such an app should contain. There aren't really that many "band apps" as such in the app store, so no precedence as to what a normal band app is has been set. That left us pondering:

• Tristania have several digital presences such as the official homepage, a forum, a myspace site, a youtube channel, facebook page, twitter account, a separate fanmade picture gallery, etc. Shall we pull in content from any of these other online sources?
• Should it be used as a promotional platform for their new album Rubicon? 
• Should the app have unique content not found elsewhere? 
• Can we somehow put in some functionality that actually uses the platform, to preemptively answer the question "why not simply surf their homepage in Safari"? 

In the end, we answered these questions with "Definitely", "Sort of", "No" and "Hopefully". 

As the "Definitely" suggests, data aggregation became the main justification of existence for the app. As we pull in data from almost all the aforementioned Tristania web resources, the application is a way for the fan to easily stay up to date with what's going on. Granted, it doesn't take that many extra minutes to manually check these different sources in a browser, but it still gives the app a sense of function.

The "Sort of" regarding promoting Rubicon is simple - we made a spotlight function where individual data from the different sources can be promoted. Right now we have Rubicon-related data in there, and as the next album draws nearer we'll promote that instead. This turned out to be an easy way to keep the content fresh and helping the band out, all without denying access to older content or having to code complicated extra functionality. 

Regarding the "No" to unique content, we've had to rethink our initial plans. Tristania used to be pretty bad at communicating with their fans, and their official homepage has traditionally been very stale and rarely updated. I therefore thought the app might be a way of getting them to share a bit more on what's going on in their world, allowing us fanboys to peek over their shoulders. Lately, however, something has happened - now they're suddenly very active on lots of different fronts (as seen in the list above), giving the fans fast and easy access to the goings on in the band. Therefore the need for an accessible information platform has been fulfilled already, and our application can take a back seat with a clear conscious. 

Finally the "Hopefully" - we have a plan to use geolocation to display all the app users on a map, and upon clicking a pin, showing that user's presentation and favourite album/track (which can be set in the discography section). This, we thought, was a nice way of tying things together, as well as actually putting the platform to use. We felt from the beginning that we need some kind of interaction, to prevent the app from feeling like a webpage crammed into the phone. We're still not sure if we'll manage to piece this together for the first release, hence the "Hopefully" instead of "Oh yeah".

YQL to the rescue

As seen above, most of the code in the app has to do with collecting and displaying external data. This has many similarities to what little brother Jacob did in his Swedish app store hit Systemet. He there put YQL to good use, and repeatedly sang its praise during the development. I never really understood what the fuss was about, but then again, I didn't really understand exactly what problem YQL solves for you, either. Of course I've seen the blog posts, read the JSMag articles, and yes, heard little brother nag, but I never saw the big picture. 

Now, as Tristania was mainly my project, I decided to try it out for myself. And, to make an already too long story short; I'm in awe. YQL does all the boring parts for me! I've just built the most extensive data collection application I've ever done, and I have almost no backend - YQL simply eliminates the need!

I realise I was slow to get a seat on this band wagon and that I'm preaching to the choir, but the meaning of this blog post is simply to join the choir and sing YQL:s praises. It's an absolutely amazing product! During this project alone, I estimate it has saved me, what, maybe 20 hours of (really dull) work. You do the math - I already owe Heilmann & co quite a hefty amount of money!

In an attempt to go more easy on the fanboy praise and become more concrete, here's what YQL has done for me in the Tristania application:

• It is, in essence, my backend. In the application I'm collecting data from several different sources, which I would then normally have to parse and scrape to get what I want and translate to a suitable data format. This is now all instead done by YQL - I simply point it at the correct location, give it a few instructions, and my app is fed with a beautiful JSON object containing exactly what I want. Even when you have a "good" data source, such as Tristania's homepage's RSS news feed, you'll still save time by piping it through YQL to get the JSON structure. Granted, I could do that locally, but now I don't have to! Of all the aforementioned data sources, only the facebook data isn't piped through YQL. Facebook's Graph API returns JSON text, which I can digest in the application through a simple call to JSON.parse. Everything else, YQL prechews for me.
• Also, YQL enables me to separate concerns and have several fragile moving parts outside the application, through using what they call a Data Tables. Data tables enables you to keep the html-depending logic in an external xml file, which through mingled JavaScript and xml (in a mind-blowingly elegant and easy solution where xml nodes are first-class citizens) defines how the parsing should be done, and what should be returned to your application. My parsing of the picture gallery especially is rather complex; the html is several layers deep, and I need to perform lots of gymnastics to figure out what's what and what I need. I could make YQL give the application the entire HTML structure in a JSON object and do the gymnastics locally, but that would mean that when the Gallery html changes, the application would break, and stay broken until we've submitted an update to the app store. Not an ideal situation. But when using Data Tables, if the Gallery changes, I can simply edit that xml file, and the applications will all start working again. 

So: If you are even slower than me and still haven't caught on - try out YQL immediately, you won't be sorry. If this was all old news to you - why the heck didn't you let me in on it earlier? 

Also, buy Rubicon, Tristania's new album, which rocks.