Design on AeroPlane for Twitter

I launched AeroPlane for Twitter and it has come a long way from a side project to a published and flourishing application on Google Play. I would like to take a step back and step through the process that made all of this possible.

  • development

  • design

  • version control

  • bug tracking

  • testing (!)

In addition, this was a challenge in so many other areas that aren’t directly related to app development but in releasing a product:

  • marketing

  • support

  • professionalism

  • publication

  • and selecting a good application name!

Since inception, I wanted to create something that people would enjoy using at the end of the day. I wanted to create something that I would even perhaps use myself. I am a huge social media geek and I ♥ Twitter. So from this, a Twitter client was born.


About the design

Logos: Airplanes in the sky

Logos: Airplanes in the sky

Iteration after iteration is apart of design, period. There is a lot of unseen work that is done before the final product is released. Good designers create products that seem obvious upon first glance but under the hood, a lot of bad and even ‘okay’ ideas are thrown into the trash along the way. But this discarding of ideas is necessary. Ideas can be conceived, fleshed out, implemented, tested and if it doesn’t work — thrown out. It’s the nature of the design process.

Twitter’s simplicity in information can be used in a multitude of ways. Its simple structure easily allows for an easy re-structure. Content arrangements, layouts, actions and animations are just a few things that a designer can play around with. As John Gruber put it: Twitter really is a UI Design Playground.

Back in 2008, I was inspired by a Twitter client that blew every other out of the water. It was a client for iPhone and it was created during a time when Twitter didn’t have an official client for iPhone yet. It was called Tweetie for iPhone and it was the gold standard of mobile Twitter clients. It boasted a simple design, used regular iOS elements (or iPhone at the time) yet brought a lot innovation such as: pull to refresh and revealing contextual actions through a swipe gesture. Both of these gestures are employed in a lot of applications today that originated from this Twitter client. Loren Brichter’s mark in mobile design will live forever.

Around when Android 4.0 was released, the Twitter client ecosystem on Android was in a similar state where there didn’t exist any Twitter clients that were beautiful. (Purely subjective, I know.) There were a lot of good ones but they were merely functional and paid no attention to design. None of them seemed polished, not like Tweetie. Some were feature packed or loaded with way too many options. Sone had major UI inconsistencies and complexities which bogged down the user experience. I wanted to create a simple Twitter app which stripped away options, settings and complexity. I also leveraged this objective in this app to showcase my design style and strived to matched the polish of Brichter’s Tweetie for iPhone.

Brichter’s use of contextual actions was brilliant. It had options for power users while keeping the UI clean for simplicity.

Inspired, I leveraged his design for contextual actions and embellished them in cards to provide the same effect.


Card UI

Animations provide context

Instead of long holding or swiping, AeroPlane utilizes a single tap gesture to bring up contextual actions. I found it redundant in other Twitter apps that tapping on a tweet would take you to a new screen which showed the same tweet again (e.g. official Twitter app) with the addition of these contextual actions. Some actions required 3 or more taps to perform an action. Why not skip all of that jazz and provide the actions inline without the need to go to a new screen? Each card has its own set of actions which is revealed on the underside of each card.

The beauty of using skeuomorphic elements is that when a user is exposed to something familiar, they expect it to behave in a familiar way — and when it does, it even gives off a sense of delight to the user that is interacting with it. Animations are a neat way to sublty communicate information for objects like: sliding in to indicate adding a tweet, flipping a tweet to show secondary actions, sliding a tweet out to indicate its deletion and so forth. It would be pretty jarring for example when deleting a tweet that instead of sliding out of view that it would vanish instantaneously — losing its skeuomorphic effect.

Each new tweet that was brought into view would slide in from the bottom. Once it attached itself to the list, it would no longer slide in again if the user swiped up and then back down. The sliding behaviour was to indicate that the tweet that came into the view was new.

Another subtle animation that I wrote was the transition between one screen of the app to another. Each new screen would come in from the right and overlay the previous screen on top. As you navigate deeper into the app, you can envision a bunch of views (or cards if you will) stacked on top of each other. If the user wanted to go up a layer of the app hierarchy, the reversal of this animation would play out and the card would pop off. This would indicate that they were removing the top card off of the ‘pile of cards’.



Designing for a more minimal approach

I decided to use a completely new screen instead. This allowed having the whole screen dedicated to this composing a tweet: using the entire screen real-estate for functional purposes.

Lastly, the biggest portion which also happens to be my favourite portion of the app is the profile.



Early mock up of a profile

Early mock up of a profile

Again, the mockup above is one of the iterations that was created to lay out a user profile. I eventually scrapped this idea because it followed a lot of what other popular Twitter clients were already doing. The key element that I wanted to ensure was utilizing the banner image that users were setting on Twitter. Using this element can really personalize a user’s profile which is evident in the final version of AeroPlane.

Instead of the above, I went for a two pane approach; one pane showing user information while the other pane: showing a dynamic list of elements depending on the viewer’s interest (i.e. tweets, followers and following.) Both panes contained transparency for the personalized background image to peer through.

The background image really distinguishes each profile from the next giving each profile a higher feeling of personalization.

The beauty about creating modular components is the ability to reuse them. Each pane above is created using pre-existing modules that were already written for other parts of AeroPlane. Admittedly, this was around the same time I was really learning about Android fragments and their ability to combine multiple ones together to create an entirely new view. I leveraged the code I wrote for timelines as one pane and added a profile information section on the left and combined the two together.

Concept of profile fragment and timeline fragments combined

Concept of profile fragment and timeline fragments combined

Using separate fragments allowed the profile information to be loaded independently of the user’s timeline. From a user experience point of view, while the the tweets are being fetched from Twitter on the right pane, the user can consume the profile information on the left.

To remain consistent with the card design I created for tweets, contextual actions for following followed suit on the back of each card. This kept consistency between how other cards behaved within the application. Using existing elements that a user has already learned is cognitively less draining instead of having to learn a new piece of UI.

Keeping contextual actions consistent

Keeping contextual actions consistent

I also intentionally let the list of tweets peek into the profile view when opening a user’s profile. This indicated that there was more to scroll to the right since you could see a portion of the list. It also served as a handy way to notify the user that the list has finished loading as it would subtly slide in from the bottom of the screen when it was finished.

Different user card layouts

Different user card layouts


About the name

It wasn’t always called AeroPlane — it was formally known as TweetFire. I wanted this application to be bold and aggressive which explains this fiery red and the current colour of the application today. However, several other names were produced over the course of a week until I landed with AeroPlane (excuse the pun.)

A lot of popular Twitter clients are named after birds and I was inspired to select a name that flew through the air. My online alias is AeroEchelon and I thought I could use a piece of my alias and through that AeroPlane was born.


Closing notes

I simply want to thank the Android community: engineers, developers, designers and lastly the users who’ve helped me along the way. Definitely watch out for me in the future and look forward to more great products to come.

Check out all of the development and design work in action on the Google Play Store.

- Flight Captain, Marvin Bernal