How we built the new Exec iPhone App(blog.iamexec.com)
blog.iamexec.com
How we built the new Exec iPhone App
http://blog.iamexec.com/post/36088710407/how-we-built-the-new-exec-iphone-app
13 comments
That ship has sailed a long time ago. Pull-to-refresh, that-slide-out-navigation-from-the-left, fan-out-navigation, parallax scrolling, all are now common iOS UI tropes that originated nowhere near Apple.
Personally I hate that back button - it's huge, but that's a pretty minor gripe in the grand scheme of things. This UI is clean, functional, and its functionality is intuitive. Pretty decent win, all things considered.
Not to mention at the very core it doesn't stray very far from Apple's guidelines - it's very clearly built around the standard navigation stack, uses segmented buttons for radio choices, puts large oversized buttons towards the bottom of a flow for completion, defaults finishing actions to the right side of the screen, uses a minimally styled version of UIActionSheet...
I'm struggling to find anything here that hasn't been seen in a hojillion other iOS apps, or even functionally different than the "standard" iOS flow. But all I see is a fairly minimal, tasteful skin over the default elements.
Personally I hate that back button - it's huge, but that's a pretty minor gripe in the grand scheme of things. This UI is clean, functional, and its functionality is intuitive. Pretty decent win, all things considered.
Not to mention at the very core it doesn't stray very far from Apple's guidelines - it's very clearly built around the standard navigation stack, uses segmented buttons for radio choices, puts large oversized buttons towards the bottom of a flow for completion, defaults finishing actions to the right side of the screen, uses a minimally styled version of UIActionSheet...
I'm struggling to find anything here that hasn't been seen in a hojillion other iOS apps, or even functionally different than the "standard" iOS flow. But all I see is a fairly minimal, tasteful skin over the default elements.
> That ship has sailed a long time ago.
But has it? The most common apps that I see people interact with are Facebook, WhatsApp & variations thereof and Apple's own apps, and they all look a lot "more native", i.e. like UIKit with very superficial appearance tweaking. (Even though FB seems to use a custom nav bar, the swipe-to-go-back gesture of iOS6 is broken).
I wish we had public app usage data... I really suspect that the average iOS screen looks a lot more old-fashioned than the average HN front-page app does.
But has it? The most common apps that I see people interact with are Facebook, WhatsApp & variations thereof and Apple's own apps, and they all look a lot "more native", i.e. like UIKit with very superficial appearance tweaking. (Even though FB seems to use a custom nav bar, the swipe-to-go-back gesture of iOS6 is broken).
I wish we had public app usage data... I really suspect that the average iOS screen looks a lot more old-fashioned than the average HN front-page app does.
I hate that back button
I have never been able to used to the back button or the bluish-gray top nav bar Apple insists on using. If I ever spend time thinking about it, I feel like puking, no exaggeration.
But my dislike for the bar is offset by rest of the device.
I have never been able to used to the back button or the bluish-gray top nav bar Apple insists on using. If I ever spend time thinking about it, I feel like puking, no exaggeration.
But my dislike for the bar is offset by rest of the device.
All that you listed relates to _interaction_ rather than _appearance_, and they saw wide adoption, because they are well thought out, innovative and inherently consistent with the iOS experience.
Gradiented button set in allcaps Proxima Nova is not. It's exactly what you said - a skin, and skinning a single app is a sure way to make it stick out as a sore thumb.
Gradiented button set in allcaps Proxima Nova is not. It's exactly what you said - a skin, and skinning a single app is a sure way to make it stick out as a sore thumb.
It's disappointing that this is the top voted comment.
If there's enough budget/time, UIs should always be built from the ground up. At every page and every element in the design process, the designer has the decision to go with:
1. Stock OS elements 2. Non-stock OS elements that follow current UX paradigms 3. Completely custom, designed from the ground up elements
As long as the designer is looking at the purpose of each page and element first and foremost, she can choose any of those options and be correct. You're right that your iPhone is not a place to drop arbitrary UI styles on, it's a place for well-designed UIs that contribute to a great user experience. Calling the design decisions arbitrary is an insult to the designer; I personally think it's a really slick-looking app with a distinct personality.
If there's enough budget/time, UIs should always be built from the ground up. At every page and every element in the design process, the designer has the decision to go with:
1. Stock OS elements 2. Non-stock OS elements that follow current UX paradigms 3. Completely custom, designed from the ground up elements
As long as the designer is looking at the purpose of each page and element first and foremost, she can choose any of those options and be correct. You're right that your iPhone is not a place to drop arbitrary UI styles on, it's a place for well-designed UIs that contribute to a great user experience. Calling the design decisions arbitrary is an insult to the designer; I personally think it's a really slick-looking app with a distinct personality.
His comment is relevant to this use case. Admittedly, if you're building an airplane flight control dashboard or an app to schedule and coordinate circus acts, introduction of a new UX paradigm is worth it.
But a new UX paradigm for messaging window, registration form, map view, person view with Call and Message actions and settings view? This is the designer making themselves employable into the future, not great user experience.
But a new UX paradigm for messaging window, registration form, map view, person view with Call and Message actions and settings view? This is the designer making themselves employable into the future, not great user experience.
On the contrary, I prefer if an app brings a unique and purpose-built UI. For example, 'Clear' the to-do list app is quite amazing. 'Paper' by 53 is another incredible interface. 'Figure' by PropellerHead is another awesome example.
Why do games get a pass, but everything else is expected to re-use the same library of controls and fonts?
I don't want all apps to look the same, they just have to be intuitive.
The examples that I listed seem to me to be developed more like a game engine... They are graphical environments, not drag & drop layouts.
Why do games get a pass, but everything else is expected to re-use the same library of controls and fonts?
I don't want all apps to look the same, they just have to be intuitive.
The examples that I listed seem to me to be developed more like a game engine... They are graphical environments, not drag & drop layouts.
I love Clear and Paper and there are more examples (Tiny Piano, Apple's utilities). But I think the difference is this: It is great if an app "becomes the device" and does its task better than UIKit could do it. But if an app does 'boring' stuff like drilling down into forms to send them, or giving the user a table of settings, then what's the reason to leave UIKit? There is absolutely no UX advantage here, to the contrary, it even has the typical "designer's back buttons" again that don't show where they lead to.
Eh…wut?
Custom UI is common in most apps - this isn't a bootstrapped app or something quick and dirty. Why would they use the default/built-in/native UI design?
Now, if you meant it's foreign because of the design style, then you may have a point. iOS apps tend to designed with elements such as textures, gradients, drop shadows, inner glow/shadow etc. While Android tends to be flat and borderless.
There were parts where it definitely felt Android/Flat (icons), other parts felt iOSish (buttons).
The custom alerts were definitely a nice touch - don't see alot of apps with custom alerts. I didn't mind them - but some may not find it as impactful as a 'real' alert (it's like a warning usually comes in red, but it's now in blue. Just doesn't carry the same weight/feeling.)
Custom UI is common in most apps - this isn't a bootstrapped app or something quick and dirty. Why would they use the default/built-in/native UI design?
Now, if you meant it's foreign because of the design style, then you may have a point. iOS apps tend to designed with elements such as textures, gradients, drop shadows, inner glow/shadow etc. While Android tends to be flat and borderless.
There were parts where it definitely felt Android/Flat (icons), other parts felt iOSish (buttons).
The custom alerts were definitely a nice touch - don't see alot of apps with custom alerts. I didn't mind them - but some may not find it as impactful as a 'real' alert (it's like a warning usually comes in red, but it's now in blue. Just doesn't carry the same weight/feeling.)
The web, a platform with seemingly unlimited extensibility in terms of UI design, has fostered some of the worst designs ever seen.... but also some of the best designs ever seen. But most importantly, we all all richer because of the competition and diversity in interfaces that it has fostered.
I don't know why you wouldn't wish the same in the iOS ecosystem as well, especially since it is an ecosystem with a comparatively better sense of taste relative to other developer communities, meaning that when it does deviate from the norm it is more likely to get it right than other communities might. Why would we want to neuter the creativity and taste that community has?
I don't know why you wouldn't wish the same in the iOS ecosystem as well, especially since it is an ecosystem with a comparatively better sense of taste relative to other developer communities, meaning that when it does deviate from the norm it is more likely to get it right than other communities might. Why would we want to neuter the creativity and taste that community has?
> My iPhone is not an empty canvas for you to drop an arbitrary UI style on.
Sure it is. Anyone can design and implement whatever kind of UI they want. If it's usable and/or accepted by Apple is a different story. You don't need to download apps you don't like on _your_ iPhone.
The UI for this app does not look all that "foreign." I am not too sure what freaks you out about their UI.
Sure it is. Anyone can design and implement whatever kind of UI they want. If it's usable and/or accepted by Apple is a different story. You don't need to download apps you don't like on _your_ iPhone.
The UI for this app does not look all that "foreign." I am not too sure what freaks you out about their UI.
Actually, an empty canvas for me to drop an arbitrary UI style on is exactly what your iPhone is. In fact, it's one of the best mediums yet invented for it.
Really curious to know why you had to reimplement Uikit uiview subclasses instead of just extending them and use ib to position them. Drawrect overriding has always been the recommended approach, and at least you can position buttons and panes and tableviews using ib , simply changing the name of the class in IB...
I'm a big fan of not using IB because code is easier to read, extract (constants, functions, component-ize), copy & paste, and version control. I also build a UIView class hierarchy so I can stash all my view-related code there instead of putting them in controller classes.
A major reason of using IB is you can position and view their layout visually. But when you build iOS apps that have (1) custom UI components, (2) uses a good amount of animation, or (3) have different enough portrait and landscape views, you can hardly see anything useful when looking at that nib in IB.
NB: re-reading this, I was more responding to Chad's point "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." rather than why not extending existing UIKit classes like UIAlertView/UIActionShet which MaxGabriel answered.
A major reason of using IB is you can position and view their layout visually. But when you build iOS apps that have (1) custom UI components, (2) uses a good amount of animation, or (3) have different enough portrait and landscape views, you can hardly see anything useful when looking at that nib in IB.
NB: re-reading this, I was more responding to Chad's point "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." rather than why not extending existing UIKit classes like UIAlertView/UIActionShet which MaxGabriel answered.
UIAlertView atleast doesn't support subclassing.
I wish this post had more specifics about the coding or design. As is, it's screenshots and generic descriptions of difficulty. It would be good to hear why you made specific design decisions, why you didn't want to use IB, breakthroughs you had creating custom UIAlertViews etc.
That type of post will be forthcoming in some of the deep technical dive posts I have lined up. They will be more interesting if I am able to open-source some of the code, but I wasn't able to get those kinds of decisions made by the time this current post was published for our launch announcement. Stay tuned.
Can you use IB when you have gone for custom UI components rather than the UIKit ones?
Yes. If the custom UI is primarily imaged-based it is easy to make with a storyboard/xib. For example, the brushes in iPhoto for iOS are made with a xib.
You know it's built this year because of its heavy usage of Proxima Nova :)
Overall, pretty clean, but could definitely be cleaner. I'm seeing four different button styles with no discernible justification for them.
Overall, pretty clean, but could definitely be cleaner. I'm seeing four different button styles with no discernible justification for them.
This is a great looking app. I'm gobsmacked by all the negative comments in this thread. Wow. Anyway, nice job.
Funny to see him talking about reading the header files of the built-in classes to guess how they work - One of the things I prefer about Android development is being able to easily dig into the source, most of it is easily understandable and it gives a good authoritative reference.
Apple has stagnated on pushing their UX design, so more and more developers and designers are breaking free from the boilerplate objects and creating their own, unconstrained interfaces that evolve beyond the patterns Apple established.
Except in this case there is no evolution just different looks. And imho a lot of wasted effort with dubious results.
If you want a good example of customization done well take a look at Tweetbot (or other apps by Tapbot).
This app? Meh.
Is this real? Not trying to be a jerk but it seems kind of crazy. Also I need a sugar cookie from harlem.
For those unaware, Chad Etzel is behind this, founded the much-loved Notifo (YC backed).
Downloaded the app earlier today. The 'Sign up or sign in' with Facebook button does nothing. Does this happen for anybody else? If this is a reoccurring bug you should work to fix this ASAP.
iPhone 5 running iOS 6.0.1
iPhone 5 running iOS 6.0.1
Yes, this is a known bug for a certain set of users (iOS 6+ with logged in Facebook credentials in Settings app) - we have shipped a fix today already. For now the only workaround is to use the "sign in/up with email" flow.
Cool, glad you guys are aware. I like the custom UI implementations. Seems like you guys spent some good time polishing up all of the core animation and stuff. Nice job!
yo, just an fyi, we just updated this bug and it is available now in the app store. one thing you might have to check is go to the Settings app -> Facebook and make sure Exec is switched to On, then the fb login button should be functional again in the app!
Cool, thanks man. Does exec work in Palo Alto or only the city?
Hey, great write-up. I feel that if you're creating a simple app you can only get so far with the built-in theming. Custom animations/themes are critical to make a fun, useful, and simple apps. I would love to see a blog post/tutorial on this topic.
So... it's a to-do list and text messaging?
My iPhone is not an empty canvas for you to drop an arbitrary UI style on. It comes with Helvetica and a whole bunch of well designed controls. I insist you use them.