Designing Flickit

Whether it’s a software application or a spatula, a well designed product is the end result in a long process. We can sometimes forget this. Looking at the finished product, it can be easy to imagine a designer bringing it to life whole and immaculate in its final form. In reality, what’s more likely is that the thing you’re looking at is the last step in a long, tiring, arduous process. A process full of false starts, failed attempts, trial and error, and “creative borrowing” from other designers. This is why I love reading behind-the-scenes accounts of the design process. I find it fascinating to learn how different designers tackle it.

Here is a little peek into my own process for designing and developing Flickit and Flickit Pro, and a look at some of the design and engineering challenges I encountered.

Design philosophy

For a while now, I’ve been trying to think of a way to summarize my approach to software user interface design. I’ve recently started thinking about modeling my UI design philosophy around the concept I’m calling the “English Butler” approach to UI design. Amongst other things, a good UI should:

  • Dress sharp
  • Be polite
  • Appear instantly when needed
  • Prepare things in anticipation of your actions

I admit I’ve never employed an English Butler, but that’s my impression of what a good house servant would be, based on what I see in the movies. Software should be the digital equivalent of the same.

How often have you used a piece of software that was ugly, rude, interrupted you at inappropriate times, was sluggish to respond to your commands, or made you perform administrative UI busywork that it could have done for you? I suspect we all have at some point. I strive to build software that is exactly the opposite of all those things.

From sketch to pixels

Most of my UI designs usually start with a sketch. At first, they are fairly rough, just to get a feel for the major components. I may do a few different screens from the same workflow at first, to get a sense of how the high-level pieces of the UI will work together. Typically all these sketches are just wireframes blocking out the major components. At this stage, a lot of crazy ideas will appear, but a lot will get thrown out as well. The goal is just to play around and experiment and generate possibilities.

After a rough wireframe is laid down, sometimes I like to dive into a little more detail in the sketch to see if the ideas in my head make any sense at all. I’ll add some refinement to placements of buttons and custom UI widgets and try to at least tease out a vision for a final UI layout.

Sketches are good for experimenting, but can only go so far. After I’ve spent a bit of time with pencil and paper, I move pretty quickly over to Photoshop to start arranging elements with correct sizes and placement.

Initial sketch Refined sketch Final UI


For the standalone Flickit uploader, I knew from the beginning that I wanted to do something unique with the UI. Anybody could create an interface to let you pick a photo from your library and then present them in a simple table or grid - I wanted to take it a step further. After a few sketches, I had the idea to make the selected photo appear as it was coming out of the camera like a filmstrip. I liked the notion that it gave the app a sort of “physical device” feel to it.

After the photo selection UI was worked out, next I tackled the problem of how to let the user enter the photo metadata and upload settings. One thing I wanted to avoid was having a completely separate screen for entering these details. I felt that bouncing back and forth between the photo list and a separate details screen could quickly become tiring if you were trying to enter details for more than a few photos at a time. I struggled for a while to come up with a way to keep the user on the same screen. Eventually I landed on the idea to “shrink” the filmstrip UI and slide in the details form at the bottom:

Animation transition sketches

I liked that you could see the list of photos at the top of the screen, while keeping the data entry part of the UI in the same screen. Tapping a photo on the top could just replace the contents of the details below without needing to go back and forth between two screens.

Surprisingly, this was one of the more challenging bits of UI to implement. The iPhone’s UIViewController framework is really only designed to handle view controllers that occupy the entire screen. Having a separate view controller slide in that only occupies a portion of the screen was tricky to get right. Also, getting all the animations right when the UI switches to the detail-entry mode and back again was a major pain. It probably took me a few days to iron out all the quirks of animating all the views with the correct transforms in the correct sequence in order to make everything look seamless.

Flickit Pro

As I mentioned in a previous post, the original Flickit app was my “test run” at iPhone development. I had a lot of fun building that app, so I set my sights higher for the next version. Flickit Pro was going to be a full-featured Flickr client for iPhone.

One of my goals from the very beginning with the Pro version was that I wanted to give the app some justification for being a native app. After all, the mobile-optimized Flickr website was pretty good. I needed to give customers a reason to use (and spend money on) a native app.

Continuous scrolling

My first target for improvement was the scrolling list of thumbnails. One thing I found less-than-ideal was the pagination of photostreams in the mobile web version. You had to keep tapping “next page” constantly. I felt that I could improve on this a bit with a native app. It was a perfect example of what I mentioned above about software being able to anticipate what the user is about to do. The app could detect when we’re getting to the end of the page and start the request for the next page automatically, saving the user from having to manually perform that action.

I set out to make thumbnail lists continuously scrolling. The app would handle all the paging requests in the background as the user was scrolling. This was a simple concept, but getting it to work smoothly turned out to be a major engineering challenge. I spent weeks on this. I probably re-wrote this part of the app 4 times before I got it to where it is now, and I feel like it could still use some improvement. There’s a ton of stuff happening on the device while the user is scrolling: network requests are being fired off, data is being downloaded from multiple sources, caches on disk are being written to and updated, and JPEG images are being decompressed. All at the same time, on the fly.


The continuous scrolling feature was cool, but I felt like the app still needed another “hook” feature. Something that would entice people to give it a try. Arguably one of the most attention-grabbing features of Flickit Pro is what I ended up calling “Photoflow”. The Coverflow/Time Machine-esque photo browser view:

Initial Photoflow sketch Final Photoflow UI

My initial designs had some fancy effects where the photos were supposed to look like they were “falling” off a ledge as you scrolled. The photos rotated a bit as they approached the viewer. In fact, this is how I implemented it at first. It turned out this was a big performance hit. I took out the tilt effect and none of my beta testers seemed to notice or care. It still looked pretty good, and scrolling performance was way better, so I left it out.

As far as the engineering effort required to build it, a lot of the work was already done after I built the thumbnail scrolling engine. All I really had to do was change which image size to load - most of the caching and request processing foundation was completely re-usable.

The hard part for Photoflow was getting the UI and interactions to feel “right”. If you’ve played around with the coverflow feature in the iPod app, you can see that a lot of effort was put into making it feel like you were really throwing around physical objects. It took me a lot of trial-and-error to give the UI in Photoflow that same behavior. (And it’s still not perfect)

At first, I tried implementing the animations with the Core Animation framework in iPhone OS. For the most part, it was working OK, but there were little glitches here and there that I had a hard time suppressing in order to make the interactions feel polished. Core Animation is very powerful, but you trade some flexibility for that power. Core Animation wants to handle a lot of stuff automatically, and if you try to subvert some of these behaviors, you run into trouble. In the end, I decided to scrap Core Animation and implement the code to animate the effects frame-by-frame myself. In retrospect, this was probably what I should have done to begin with, since it wasn’t really that hard. This gave me full control over how the images behaved and all the edge-case problems I had with Core Animation were eliminated.

Keeping Tabs

A big challenge for writing an iPhone app for a site like Flickr is figuring out how to take all the different navigation options available on the full website and boiling them down into a format that makes sense on a tiny iPhone screen. Your main home page on Flickr has 6 menus on it, and each menu has between 5-17 items in it. Lots of navigation possibilities. How do you present all these options in a way that makes sense on the iPhone?

Tab layout sketch

One thing I didn’t want to do was to create a tab bar with 17 items in it. In fact, in general I think creating a tab bar with more than 5 items in it is a bad idea. Yes, the iPhone will automatically place a “More” tab in there for you, but this is a bad user experience.

Any time you have hidden UI elements in an interface, that increases the cognitive load for your users. They have to create a mental image of all the tabs behind that “More” link every time they use your app. This usually ends up causing a lot of hunting and pecking around in your UI and generally leaves the user feeling lost. Better to have 5 solid tabs. This way, there is never any confusion about where to go. Launch the app, see 5 tabs, that’s it. This will keep your users feeling grounded.

Infinite linking

Another problem with a site like Flickr is that everything is linked together. For example, from a member’s profile, you can go to their photos, then navigate to sets/tags/groups, then more photos. Or, navigate to a photo in their favorites, then pivot to the owner of the photo, see their favorites, etc, ad infinitum.

On the web, this is great because you can jump from link to link and have great time exploring. Everyone is used to using the back button or history list in their browser to navigate backwards.

In a native iPhone app, this causes a bit of a problem. One way that some apps achieve this type of link-hopping navigation is to keep pushing new views onto the view stack. If you allow this kind of navigation, then pretty soon you’ll find yourself 10 levels deep in a navigation stack with no easy way to get back to the root of where you started your navigation. The iPhone’s navigation stack doesn’t really provide an easy way to see the breadcrumb trail of your navigation - you’re stuck hitting the back button 10 times to get back to the root. To get around this, some apps introduce a “tap and hold” gesture on the back button to automatically go back to the root. This kind of thing feels like a hack to me. It’s unintuitive, and most users won’t discover it.

I made a conscious decision to prevent this kind of infinite deep-linking in Flickit Pro. You’ll notice that no matter how you tap around in the app, you’ll eventually always end up in a dead-end. (Usually a photo screen)

Navigation sketch

I designed the navigation this way purposefully, to try and prevent users from getting lost. This decision has some drawbacks. Namely, it prevents the kind of exploring that you sometimes want to do. For example, following a photo in the “Interestingness” list to that member’s photostream is currently not possible in the app. I have some ideas for how to get around this problem, but I decided to hold off on implementing them until I was sure it was the right approach.

It’s always easier to add new features than to remove or change existing functionality.

Deleted scenes

No “behind the scenes” post should be complete without a look at some of the designs that didn’t make the cut. Sometimes, seeing what was removed can teach you more about the process than what was left in.

Most of the time, I throw out ideas early in the process, in the sketching phase. But sometimes, I like to take an idea a bit further. I toyed around with this concept for a different take on the standard “list view of contacts” for the People tab in Flickit Pro:

Un-used 'People' screen

The idea was that your contacts would be presented in the scroll-wheel at the top. By rotating a contact into place in the center, the bottom area would update to show that contact’s most recent photos. An indicator under the contact’s avatar image would show which contacts had new uploads since the last time you checked. I thought that this might be an interesting way to present two levels of information in a small space: contacts + recent uploads.

In the end, I decided to scrap the idea due to the development effort required to implement the scroll wheel. It was getting late into the development process, and I didn’t want to hold up shipping the app any further. Perhaps this idea will find it’s way back into the product in a future version.

You can still see some vestiges of this design in the final product. Namely, the “new uploads” indicator was something I thought could still add some value, with minimal implementation effort.

I could go on, but this post has gotten a lot longer than I thought it would. If you’d like to hear more about specific design decisions or engineering challenges, leave a comment with a suggestion and I’ll do a follow-up post.

You can also check out more pics of Flickit’s design journal on my Flickr photoset.

blog comments powered by Disqus