You've heard about about Spaz before, a Twitter client for the Mac (as well as Windows and soon-to-be Linux). We're growing fans of the app, but we still didn't know much about the impetus behind it. Written by Ars regular Ed Finkler, the Adobe Integrated Runtime (AIR)-based app has been making some serious progress since its inception, blossoming from just a random side hobby to a much more serious application (as "serious" as a Twitter app can be, anyway).
Spaz recently won the award for Best HTML Community Application at the Adobe AIR Developer Derby (check out Ed's interview at Adobe EDGE Magazine), which pushed awareness of the app through the roof. Now, Ed says that he is constantly churning away at Spaz, trying to make it the best Twitter app out there. We took some time to
slip into something more comfortable chat with Ed when he was in Chicago for the Adobe MAX conference to find out a little more about Spaz's background, how it differs from the competition, what's the deal with AIR, what we can expect for the future, and more.
We know that you initially wrote Spaz on a whim, but now it's really beginning to take off as a well-respected Twitter client on multiple platforms. Do you have future plans for Spaz?
Oh, most definitely. There are lots of things in the Twitter API that I'm not taking advantage of yet, and there are lots of new features in AIR Beta 2 that would be useful for Spaz. The development model will stay the same, though—an open development process of an open-source application, relying on feedback from users and frequent updates.
What kinds of things can we expect in future releases of Spaz?
Recently, I've just been getting Spaz up to speed on AIR Beta 2. Version 0.2.6, which was really a compatibility release, was rougher than I usually like. There was a huge shift in the security model for HTML apps between AIR Beta 1 and Beta 2, and it came little more than a week before the public Beta 2 release. The Beta 2-compatible Spaz probably wouldn't be out yet but for the massive help of some of the guys from the AIR engineering team (especially Alexandru Chiculita), so big props to them. We're now currently on 0.2.7, and expect to release 0.2.8 within a few days.
Some of the things on my feature to-do list (not necessarily in order of priority) are:
Adding and viewing "favorite" tweetsSome sort of TinyURL or urlTea integration to insert short linksFollower blockingEncrypted storage of authentication info (this was just made a whole lot easier with AIR Beta 2)Option to not save your passwordStorage of multiple username/password combos and faster account switchingAuto-completion of follower/following usernames when typing "@" or "d "Viewing large-format versions of user avatarsability to view your sent direct messagesSome kind of mapping integration to plot the locations of your followers/people you're followingsome sort of integration of your main timeline, your replies timeline, and your direct messages timeline
Spaz's different looks
How do you feel Spaz compares to Twitterrific on the Mac? What does it do differently?
Here's a super secret: I've never used Twitterrific. Not because I'm a bigtime hater, but because I didn't want to get depressed about my own abilities and give up. I've avoided using most other Twitter clients for this reason, and also so I didn't just slip into some sort of feature duplication competition. I suppose I'm quite the opposite of the "Delicious Generation"—I strive for humility, and am not interested in making bold claims about the awesomeness of my kung-fu. I'm pretty good at some things and I suck at a lot of things.
That being said, I've had plenty of people tell me feature differences in Twitterrific, and there are are certainly some significant technical differences. I'll try to break down the ones I'm aware of:
Spaz is cross-platform: not a big thing for people who only use Macs, of course, but people who use Windows as well can run Spaz, and eventually Linux users will be able to as well (when AIR is ported to Linux)Spaz offers access to more data, like your "replies" timeline, your sent messages, and users you are following/who are following you.You can delete messages you've sent from SpazYou can do some basic follower management in Spaz, although this could be improved a lotSpaz uses encrypted connections (https) to talk to Twitter whenever possibleSpaz is themeable/skinnable: users who are comfortable with CSS can modify the existing themes or create their own themes.Way more bugs: I guarantee it!
Why did you choose the AIR platform?
There's a bit of a story to that. I've been doing web design for about 11 years, and web application design—server-side development—for about 8. The jobs I've had over the years have inevitably involved both front- and back-end development, but most people know me as a PHP developer and web app security guy.
Still, I enjoyed toying with desktop apps from time to time. I liked the OS X platform for development a lot, but I wasn't really into Obj-C much as a language, so I ended up doing a couple things in RealBasic. Some folks might remember a LAME-based mp3 encoder/CD ripper called LameBrain; that was one of my projects.
Early this year I really got an itch to revisit desktop app development, and a Twitter client seemed like a good choice. The service was something I used from time to time, and it had a simple, powerful API. Spaz's early incarnation was built in RealBasic, and while I don't think it was much to look at, it was functional (not sure I could say more than that).
One of the things I discovered early in making desktop apps is that certain things that are simple to do on the web are enormously difficult in a desktop app. Getting user pics to display next to posts was a great challenge, because you can't just say "grab the image from this URL." You have to do all the heavy lifting the browser would do for you on a web page, like retrieving the image via HTTP, loading it into memory, drawing the image into the correct location, and caching the image—and you have to do it "asynchronously," so you can retrieve more than one at a time, and you don't have to wait for the process to complete to scroll your timeline or whatnot.
Eventually I hit a roadblock: I wanted to have URLs inside "tweets" be clickable. This looked like it was going to be next to impossible, or at very least so difficult that it wasn't worth the time. Spaz didn't get worked on for a few weeks because it seemed like a dead-end.
My first proof-of-concept was an AIR app built on Beta 1 that just loaded and displayed the Twitter public timeline, auto-refreshing every minute. Getting that working was surprisingly easy, in part because I was using the Spry JS framework from Adobe, which makes grabbing data from various sources and displaying it in HTML a piece of cake. That early prototype looked much better than the original Spaz, and it was much, much faster to develop.
Speaking of AIR, congrats on winning the AIR Derby! What did you think when you found out that you had won?
To be blunt and uncouth, I shit a brick. It was quite unexpected. I suppose I thought I had a chance, but I tried not to get my hopes up, because there certainly are lots of other people who were far more experienced with RIA development than myself. I was actually at a PHP conference in Atlanta when I got the call, and it was hard not to be overly giddy and annoy all of my fellow conference attendees with the news. I couldn't say anything publicly for about two weeks because they were announcing the winners publicly at AdobeMAX 2007 in Chicago.
That reminds me, I have to call my parents and tell them.
You got some sweet prizes as part of your winnings. What's your favorite?
I think I'd get stoned to death if I didn't say the 8-core Mac Pro, but I do like the two 27" monitors a lot as well. All of the parts of the prize package add up to a really great dev environment, so there aren't any I'm not excited about—even the squishy ball.
Anything else you'd like to add?
To mitigate this problem, the AIR team created a "sandbox" model. Two sandboxes exist: the "Classic" sandbox, and the "Application" sandbox:
To get data back and forth between the two sandboxes, you create a "bridge" object, and create hooks that allow the Classic sandbox to get info from the Application sandbox and vice-versa. The model is similar to the client/server model in browser-based applications, and similar care should be taken — you don't want to, for example, let the client side of your browser-based application read any file it wants to on the server.
It's my hope that JS framework creators start to drop the dangerous practice of using eval to decode JSON, and switch to deserializers that don't execute any code.
Thanks Ed for taking the time to talk to us!