Design Assembly

You’d have to have been living in a hole not to have heard of Twitter. With lots of exposure from celebrities such as Britney Spears, Shaquille O’Neil, Stephen Fry and Barack Obama it really has entered the mainstream. However, most users’ experience of Twitter is via the twitter.com web site. But there is an altogether more pleasant way to engage with Twitter.

There is one desktop Twitter app that stands out for me as a well designed, thought-through piece of work. DestroyTwitter is a minimal, very usable app with great support. It’s an Adobe AIR application so is cross-platform (Mac, Windows and Linux), however this isn’t the product of a company or even a small team of designers/developers. DestroyTwitter is designed, developed and maintained by one man – Jonnie Hallman. Not only does he work on this project alone, but he also holds down a job and is studying for his degree.

The name DestroyTwitter comes from Jonnie’s web site DestroyToday. The ethos behind the name is “to destroy today is to make the most of the day — destruction as a form of creation”. Prior to his Twitter app he created DestroyFlickr; an AIR application for browsing Flickr photography.

How Jonnie finds the time to develop DestroyTwitter is beyond me… so I thought I’d ask him along with a few other questions.

MK:
DestroyTwitter is obviously technically complex. With a design background academically as well as professionally, how did you pick up the skills to build your own AIR app?

JH:
I can’t remember how I heard about AIR, but began developing with it ever since the beta was available on Adobe Labs. At the time, I needed an idea for an independent study, so DestroyFlickr became my semester long project. Since AIR is an Actionscript (AS) 3 package, it’s really easy to pick up with a solid foundation of Actionscript. I spent the prior summer transitioning from AS2 to AS3 and from Flash to Flex, so it worked out perfectly. All of the developing skills I have now are a result of endless hours guessing and checking. At first, I had to research what was possible, but now that I’ve worked with AIR for a number of years, it’s just a matter of which approach to take.

MK:
Do you see the coding element of the work as an extension to the design process?

JH:
Of course. Coding has to be designed along with the physical aspect of the project, which makes for nonstop decision-making. I quickly learned how important it is to build a personal set of standards to abide by. I’m pretty meticulous with my rules and tweak as I go—everything must make complete sense for it to work well. Sometimes projects can get out of hand when met with a tight deadline, which usually results in a slip in the coding style. I always find myself panning between the clock and some sketchy code I just wrote, contemplating whether I have enough time to revise. In the long run, the answer is always yes. Poorly-considered code can ruin a project’s life.

MK:
You get a fair bit of feedback from your users via Twitter which you actively encourage. How do you decide what, if any, features to add at their request?

JH:
That’s such a great question. It’s a struggle of pros and cons, really. There’s a number of stages I use to decide, but most importantly, I weigh the feature’s benefits in the long run versus its toll on memory usage, usability, and design. If it’s not a necessity, forget it. If it gives the user more of a choice and doesn’t hinder the weight or performance of the app, why not. Most feature requests are a simple yes or no because they’re light enough to weigh easily, but a few are worth a solid night of sleep. If a single feature is requested a dozen times, it’s probably in my best interest to highly consider it, but that doesn’t mean it’s a definite yes.

MK:
DestroyTwitter is visually minimal and shares a common look & feel with your previous AIR app, DestroyFlickr as well as your web site destroytoday.com. Was this a conscious decision or driven by your desire to keep the application resource-light?

JH:
The design of my work comes from the simple, to-the-point style I’ve been drawn to over the years. At first, I thought the minimalist style attracted me because it’s easy to program, but I quickly realized it fits well in the context of my work. I mostly develop websites and applications, which both require an emphasis on usability and intuitiveness, so it’s best to keep things clean. The apps and website originally weren’t designed with consistency in mind, but I think it’s a strong way to tie everything together. I’d love to work on a project that breaks my style, but haven’t had a chance to do so yet. I came about my current palette a bit differently than normal. Prior to DT, my swatches were all bright and colorful, but these past few years have taken a toll on my eyes, resulting in the darker colors. They’re just easier for me to work with.

MK:
With a fair few competing Twitter desktop clients available, a few from some fairly big players, why do you think DestroyTwitter is doing so well?

JH:
I used Twitter for about a week before deciding to develop DestroyTwitter. It was a tough choice to make, weighing whether or not the world needed yet another Twitter app — and an AIR app at that. In that week, every app I tried had something about it that caused me to look elsewhere. I felt determined to use Twitter, but I just couldn’t get the hang of it with the available clients. After using them, I spent a few more days comparing their pros and cons—what wasn’t working for me and how could I make it work. I combined my research with a few polls I tweeted and the ball started to roll. I wanted a simple app that runs in the background. Tweeting should be as easy as responding to an IM. Most of all, it should be enjoyable to use—something that makes you want to tweet more. After a few releases, I knew it was worth it. Those using DestroyTwitter were anxious for updates and I was just as anxious to develop them.

MK:
You’ve recently added the ability to customise the DestroyTwitter experience. Did you not feel there is a certain amount of brand value that would be diluted by giving users this power?

JH:
It was a tough decision. In the beginning, I felt reluctant to offer color configuration, but over time, I had a change of heart. Originally, I thought of this feature as it is in other clients—in the app with a few parameters and completely constrained to the computer it runs on. I considered AIR’s ability to register custom file types and knew this could kill a few birds. It would keep color configuration separate from DestroyTwitter, which saves memory and refrains from cluttering the already overflowing preferences canvas. And since it’s separate, there can be an extensive list of parameters, customizable with any text editor. Best of all, it opens up the aspect of sharing, building upon the growing DestroyTwitter community. After testing the feature with a few fellow designers, I could see from their themes that it was a good move. People have already started to “brand” DestroyTwitter with their colors and it’s exciting to say the least.

MK:
You’re developing DestroyTwitter on your own. With a job and a university course on the go, how do you prioritise these different facets of your life?

JH:
It’d be so much easier if there were more hours in each day. Luckily for me, an odd turn of events allowed me to open up my schedule a bit. I planned to graduate early from the get-go, so I stacked up on classes. Mid-junior year, I decided against this, which dramatically lessened my course load. All of a sudden, I was taking only four courses instead of six. Inevitably, my hours increased at work, but I managed to keep a solid balance with school and projects. I wake up early, work non-stop through the day, and get to bed on time—I think. I try to take advantage of every chance I get to plan this or that, especially when my laptop isn’t within reach. Art history provides a solid three hours to decide which features will make it into the next release.

MK:
As DestroyTwitter’s popularity increases, it is bound to take up more and more of your time. Do you see a time when you will stop developing the application further. (Additionally its functionality is limited to the functionality of Twitter, so does that limit its update-ability)?

JH:
I think about this a lot. I’d love to work on it full-time, since I’ve gotten pretty used to it already. I see this summer as a real deciding point for DestroyTwitter. I recently chose to use it as my senior thesis with the goal of bringing it out of beta alongside its dedicated website. I can’t imagine where DestroyTwitter will be at that point. Regarding Twitter, its API is somewhat limited at the moment, but I’m really looking forward to any additions they have planned. You’d be surprised how much can be done with a single stream of tweets though. If it were possible, I’d spend the rest of my life developing these projects. Unfortunately, it’s not that easy, but if you know of any available grants, I’m all ears.

MK:
Is the simplistic methodology of Twitter a hindrance or a help with regards to building a desktop client for it?

JH:
It’s actually a big help. A combination of Twitter’s limited aspects and the typical user’s workflow of read/reply/retweet make it easy to focus on building an app. For core functionality, one needs a tweet stream and the ability to tweet—the rest is up to the developer. The tough part is coming up with a unique feature that the thousands of Twitter apps don’t already have.

MK:
What are your main design influences and are any apparent in the design of DestroyTwitter?

JH:
I’m really inspired by the “bare-essentials” aesthetic that is becoming more and more the norm. Look at any website pre 2000 and every single page is filled with animated GIFs and scrolling marquees, even my MICA’s. For a while then, it was all about Apple’s aqua look—every button needs the glossy reflection and soft gradient. With each year that passes, the gradient becomes softer and the glossy becomes more matte. I’m more drawn to the use of simple shapes and crisp edges, which is why I use it in my work. It’s just easier for me to get along with.

MK:
A few years ago designing and developing a desktop application would more than likely involved a multi-disciplinary team where now it is relatively easy to do something like DestroyTwitter on your own. Are people still surprised to find out that there is only you behind DestroyTwitter?

JH:
I think more people would be surprised if I didn’t maintain a strong personal presence on Twitter or through email. I try my best to respond as soon as I can to any questions or comments directed my way, and I get more “Thanks for the quick response!” than “Thanks, you guys!” It’d be nice if Destroy Today was more than myself, but I like it this way—it’s something to keep me busy. I wonder if it will someday become a studio or dev team, but it’ll need strong clients who aren’t scared by the name. That’s one thing I’m surprised about, but it’s expected.

MK:
Do you have any plans for any more sibling applications to join the DestroyToday stable?

JH:
DestroyTwitter isn’t stable just yet, but when it is, I’ll begin planning a new project. I think DestroyTwitter is my last venture into the API world though. As easy as it is to play with the API of an existing service, there’s a part of me that wants to develop an original service and provide an API of my own. What it will be, I have no idea, but I’m anxious for it, whatever it is. If it takes a few decades to think up, so be it. We’ll just have to follow-up on the interview then.

Links:

DestroyToday
www.destroytoday.com

Download DestroyTwitter
www.destroytwitter.com

Adobe AIR
www.adobe.com/products/air/

Download the Design Assembly DestroyTwitter theme

And if you fancy it… You can follow me on Twitter
twitter.com/n_smooth