By Karen Cheng, App Designer
The brand new Exec v2.0 iPhone app was a three month effort to completely rewrite our existing app from the ground up. Karen (our designer) and I worked together to create a beautiful and fun experience for our customers. In this post I detail the process we used to work together to deliver the final product.
Starting From Scratch
When we decided to release an update for the app, the team sat down and listed all the new features and updates we wanted to add to the new version. After looking at the list, we decided it would be in the best long-term interest to start entirely over with a new code base.
The decision was overwhelming but freeing in a lot of ways. It let Karen reimagine the visual design of the app and it allowed me to completely overhaul the infrastructure of the app starting with the data-model and networking layers. Exec v1.0 relied heavily on the thin-client model and almost every tap resulted in a server call. Almost nothing was stored on the device. I wanted Exec v2.0 to have much heavier client-side caching and reduce the number server calls the app had to make between interactions.
While I was busy laying down the initial infrastructure code, Karen was extremely busy working on initial design mockups of an overall design theme for the app. When the team was happy with the overall look and feel, she set about creating app specific screens.
Karen used Prototypes to quickly create prototype versions of the app to share with the team to gather feedback and do some outside user testing. Finally we were ready to start implementing the visual design and main functionality in code.
No Pixel Left Behind
Karen wanted every screen to look just right, and rightly so! She printed them all out and marked the exact pixel dimensions and RGB value of every little detail in red ink.
This process is also known as the designer torturing the developer. Karen Cheng (Designer), left. Chad Etzel (Developer), right.
The Development is in the Details
When Karen delivered the first mocked up version of the new app it looked gorgeous, but I thought, "What is this madness?" There was not one native UI component in sight. Everything was custom designed: navigation bars, back button items, action sheets, alert views, table view cells, segmented button controls, and even some new UI components like status bar notifications and loading views.
True, there are "appearance" proxies for several UI elements in iOS 5.0+, but several of the visual design choices meant that a completely custom implementation was the only solution.
A custom alert view
Custom action sheet
Custom status bar notifier that displays from the navigation bar to give extra contextual information.
Custom activity indicator/loading view to indicate long tasks like server calls
Grouped table view cells with custom border and dividing line rendering.
This posed quite a challenge. I was used to only using native UIKit controls which give a good enough look and feel for most apps. However, we wanted this app to be extremely well polished, and using basic components just wouldn't cut it.
So, off to the documentation I went. I read up on UIView and CALayer which is where the main power of UI rendering takes place. This also gave me a great opportunity to learn about Core-Animation, especially CAKeyframeAnimation which was used extensively to add some subtle animation effects to the UI which make the app more fun to use. By the way, if you are creating your own custom animation timing curves, I found the Animated B&eacute;zier Curves page a great resource for choosing proper control points for the timings.
When creating custom clones of standard UI components (such as UIAlertView and UIActionSheet), I found it very helpful to read the header files of each component. These files gave great hints as to the internal workings of each component by looking at the instance variables. They also gave the public properties, methods, and delegate protocols I would need to clone to make my custom class a drop-in replacement for the standard control. The hard part then became implementing the custom drawing and layout methods needed to create the exact visual design that Karen had created in Photoshop.
It was a lot of work. A good percentage of the development cycle was devoted to these custom controls. In the end it was well worth it. Every aspect of the app feels congruous, and all the components (nicknamed ExecKit) can be quickly reused in subsequent apps that we may create.
iPhone 5 introduces a taller screen, mid-cycle
Having over 30 screens to program (no Interface Builder here) meant that an overwhelming majority of the time on the app was spent writing interface code. The nice thing about iOS programming is that every iPhone and iPod device screen has the same dimensions. This allows for pixel perfect graphic designs (and why I think a higher percentage of iPhone apps look extremely well polished compared to Android apps where the screen size fragmentation makes it almost impossible to do pixel perfect design).
Right in the middle of our app update cycle, Apple decided to release the iPhone 5 with the first new screen size for iPhones and iPods since the first iPhone was released. This threw a bit of a wrench into our screen layouts. Luckily, I have developed several apps with programmatic views and have my own set of UIView layout helper macros to dynamically position views relative to each other. It turned out that the only adjustments needed were to set a few elements' autoresizingMask to a different value and everything magically worked with the same code on different hardware. The only screen size dependent code involved displaying different sized full screen images in the onboarding views.
Extra Polish with some Easter Eggs
The Exec Man
If you've used the Exec app before, you might be familiar with the running man icon, which shows you where your Exec is on the map. We thought it would be fun to show different icons depending on what the job is. Our algorithms detect your job category and show you an icon accordingly.
We went through hundreds of sound effects to make sure every pop and click was just right. We wanted every press of the buttons to feel satisfying, like closing a car door.
Midway through implementing the sounds, I jokingly recorded my voice for some placeholder sound effects. Light bulb! It would be hilarious if we had a mode of human sound effects.
So we did it. The Exec app has a human sound mode, lovingly performed in a capella by the Exec team.
Coding custom components and implementing intricate design was just one aspect of creating this app. The data modeling, API, and networking layers were rewritten from the ground up for this new version and will be the subject of a deep technical dive in an upcoming post.
Grab Exec v2.0 here!
Exec is hiring! If you want to work with top-notch developers, designers, and all-around cool people you should apply today!
Posted November 19, 2012