Iterating to an Ugly UI

I've been working on an app for golf courses that gives golfers range finding and the latest weather. The concept and app are rather simple, so I decided to spend some time perfecting the design.

After deciding on tab bar navigation, I needed to create the view the user sees immediately after launch. The first view is a list of holes on the course with some branding and supplementary information.

Initial course list sketch

My usual first step, when I start a brand new design, is to hop onto Dribbble and see what the latest trends are. I've done enough searching on Dribbble to know to first search "ios7 list" and sort by "Popular".

Dribbble results for iOS7+List

I took the Dribbble search results and created my first design.

First Design Concept

I tried to make the app look "iOS 7" by blurring a photo of one of the holes and placing it in the background. Each hole only shows the hole number, par, and yardage for a single tee.

The spacing between each hole would give me room to create some dynamic animations. Maybe keep the blurred background in place and slide in the map of the hole.

If you ask me, this is a weak use of screen real-estate.

I really liked the hole number green with a white, inner border. The style should be familiar to most golfers.

Second Design Concept

This second design iterates on the first only adding a feint line connecting each hole. The line reinforces order, kind of like a golf cart trail between each hole. The actual data that's displayed doesn't change at all.

Third Design Concept

Not much changed on the third iteration, only the cell layout. Putting everything on the same line and reducing sizes put more holes on the screen at once.

Fourth Design Concept

I ended up getting carried away with the idea that more holes on the screen means better layout.

Its a wreck.

Taking a step back, I saw how I was digging a deeper and deeper hole. I needed to stop staring at the trees and start focusing on the forest.

Final Design Concept

The fifth and final design heads in a new direction. I refocused my efforts, deleted my Dribbble Inspiration folder, and thought critically about how this screen would be viewed.

I realized that golfers were going to be in direct sunlight trying to read text on a glossy, finger-smudged screen. I got rid of the background blur and used black text on white for maximum contrast and readability.

The only information that really matters on this view is the yardage for each tee box, hole number, handicap, and par. The rest of the data should be in the hole views or elsewhere in the app. The new data layout is light and balanced.

I also removed every animation. Course data is loaded from local resources, so a fancy animation isn't masking any work. Users would just end up waiting, and they frequently like to complain about how annoying pointless animations can be.

I'm quite happy with the final design, but you won't catch me posting it on Dribbble, because it doesn't really follow any design trends. It's ugly.

And that's a good thing.

The final interface serves its purpose. It presents basic course information, removes distractions, and is completely accessible. Sometimes following trends for the sake of being trendy creates Dribbblisation and hurts the usability of your product.

Custom View Controller Transitions with Orientation

When iOS 7 was announced at WWDC in 2013, there were an incredible amount of new APIs that caught my eye. Watching one of the developer sessions from my couch in Ohio a few hours after it took place, I stumbled upon session 218: Custom Transitions Using View Controllers.

This session contained a lot of confusing information about an incredibly exciting new API. I say "incredibly exciting" because graphics and user interaction on iOS are what really get me going. I love exploring and discovering new ways to delight my users.

The core functionality of this new API uses the protocol UIViewControllerAnimatedTransitioning.

This is how Apple describes the new API:

View Controller Custom Transitions described by Apple

If you're confused, don't worry, so was I. This screen cap just about sums up the entire session 218 video as well as the sample code.

I was really hoping we'd get to see some examples of how Apple created their custom transitions, but the only sample provided performs a simple transition using UICollectionViewCell animations, which is a little different than the UIViewController transitions they demo in the session.

I'll attempt to explain how UIViewControllerAnimatedTransitioning works as briefly as I can.

You are currently looking at view controller A and want to present view controller B.

View Controllers A and B

You initialize a transition and are given a container view that facilitates the animation of your transition.

Adding VCs to Container View

Add view controller B's view to the container.

Adding B to the container

Perform an animation on the views of view controllers A and B (not on the container).

Simplest of all animations

Afterwards you're left with view controller B presented, and, by calling animationEnded:, the presentation is completed.

Recently Ash Furrow and Bradford Dillon created some really great posts on custom UIViewController transitions on Teehan & Lax's and Double Encore's blogs, respectfully.

Both guides are great and do a good job at explaining how to create your own custom UIViewController custom transitions from scratch. However, both fail to explain how to implement proper orientation support.

Teehan example orientations

I started experimenting and quickly found what I thought to be a bug. On July 15th I filed my first bug report with Apple (#14444833, thanks for those who resubmitted). I also created a thread on the dev forums that got some attention.

No one ever got an official answer.

After some digging, I found that the container view's frame is always laid out in portrait, even if the device is in landscape.

The frame layout was likely our biggest source of confusion.

It took a lot of tinkering, but I finally found a useful solution. Even though the frame of the container view is stuck in portrait, I found that the bounds of the container view is always corrected for device orientation.

I'm not entirely sure that this is intended, but since the container view should be agnostic of your view controller hierarchy, it shouldn't necessarily adjust for orientation.

From the frame documentation:

The frame rectangle, which describes the view’s location and size in its superview’s coordinate system.

From the bounds documentation:

The bounds rectangle, which describes the view’s location and size in its own coordinate system.

The view controller transition API is simply too vague in its current form. More sample code and documentation really needs to be provided. But for now, if you're going to use custom view controller transitions, make sure to adjust your new views with the bounds of the container.

I've setup a Github project with examples using code, NIBs, and Storyboards. Please feel free to use the code from my transition controller as a starting point. Hopefully this will provide a good starting point to perform awesome, oriented animations.

Live Blur in iOS7

Lately I have been seeing a lot of designers on Dribbble using blurs in UI concept animations for iOS 7. These designs are usually flat and apply a gaussian blur to the contents beneath views. Apple has demonstrated this technique in their design of iOS 7 with Safari's tool bar and Contact's tab bar.

In design, blur is primarily used to corral your eyes towards an object. If you are presenting a modal atop a busy background, a blurred background will naturally guide your eyes towards the crisp and in focus text or images.

Blurs also help present additional information while remaining within the context of the previous screen.

iOS 7 Alert View

Below is an example iOS 7 custom control design by Jakub Antalik. I took this beautiful design as a challenge to recreate it as an open source iOS control. I've done these sort of challenges before, so I didn't think it would be too difficult.

Sidebar calendar animation

Unfortunately in the latest iOS 7 SDK, there is no API to do live blurring of a view. When I say "live blurring" I mean applying a gaussian blur to a screenshot of the contents beneath a view and maintaining the blur effect throughout animation and state changes of the background.

There have been some great attempts at creating "live" blur views for iOS, the two most notable being FXBlurView and ios-realtimeblur, but these projects work by continuously polling the runtime, grabbing screenshots of the current view (which occurs on the CPU and main thread), applying a blur to the screenshot, and then adding the image to the view. The "live" effect happens by quickly swapping the blurred image with another, working just like frames of film.

The big bottleneck with most of these implementations is the screenshot process. This operation has to occur on the CPU which delays other, more critical operations, and can lag and stutter on older devices.

Rumors have hinted that Apple is blurring directly on the GPU, but creating such an API would open up security risks, and we've seen how Apple deals with security issues.

One trick that I've experimented with is changing the UIViewContentMode property of UIView (usually UIImageView) to be fixed to a side, and then animate the height or width of the view so it looks like a live-blurred view is sliding in.

RNFrostedSidebar blur hack

I implemented this trick in my RNFrostedSidebar UI control and I think the effects are quite nice.

RNFrostedSidebar open animation

Until a background blur API opens up, I strongly suggest keeping blurs in your designs to a minimum because they can be pretty taxing on the device and hurt user experience. Just remember to keep performance in mind as we design and develop our UIs to match this new iOS.