I was a guest on this week’s Accessible podcast by Steven Aquino and Ben Alexander. We talked about teaching Siri to understand folks who stutter; how my wife is much smarter than me; what Ellie Sattler’s Jurassic fern frond has to say about iOS 7; web leather, mobile leather; and how a pile of dog parts on your living room floor doesn’t make a Lassie.
This app is unabashedly my vote for the best iOS-6-to-iOS-7 redesign I’ve seen. It retains the spirit and flavor of the previous version, while still treading safely within the new flatness dictated by iOS 7. Get it here.
Playful animations are easy to spot but not overbearing, which is difficult to achieve. My favorite animation is the animating hearts when tapping a like button (I sure hope people don’t get push notifications every time I tap a heart button, because I can’t keep myself from tapping them again and again).
If I could change one thing, it would be the use of the blurring views behind the status and navigation bars. They’re so heavily tinted blue that the resulting effect is a distracting flicker when scrolling. The true purpose of iOS 7’s blur is to create the illusion that your “content” is always visible, even from behind a navbar. This goal would be better achieved in Tumblr’s case by using semi-translucent non-blurring blue bars.
Together with Justin Williams, I recently announced an open-source iOS sharing library called OvershareKit (available on GitHub). It makes it trivial to add rich sharing options to your iOS apps. There’s enough material in OvershareKit to warrant many blog posts, but I figure I should start with some of the cooler bits that you might not discover right away:
OSKTextView: A Better UITextView
OvershareKit comes with OSKTextView, a fork of JTSTextView, my open source UITextView wrapper (until Apple fixes some bad iOS 7 bugs with UITextView). The OvershareKit version has some nifty additions. It can highlight links, hashtags, and @mentions as you type. You can move the cursor with the Riposte-style swipe gestures: one finger to move by character, two fingers by words, and three fingers by paragraphs. It also automatically converts dumb quotes to smart quotes.
Built-In Support for In-App Purchases
This was Justin’s killer idea. Your app may have certain sharing activities that require in-app purchases (e.g. Riposte only shows the OmniFocus and Things options if you’ve upgraded to Riposte Pro). Why hide those from the share sheets, when OvershareKit could do more? Once you mark your chosen activity types as requiring in-app purchase, OvershareKit will badge those activity icons with little price tag indicators until they’re purchased. If a user taps one of them, OvershareKit queries the relevant OSKPresentationManager delegate for your custom purchasing view controller. You are still responsible for making the purchase from the App Store, and for storing/validating purchase receipts.
Optional Dark Mode
More and more customers are realizing how nice it is when an app shifts to a low-light mode or “dark mode” during evening hours. OvershareKit has an optional dark mode setting, which you can trigger through the OSKPresentationManager’s style delegate. You can also customize many of the default colors.
The username / password screens in OvershareKit show 1Password search buttons if that app is installed. Tapping the button launches 1Password with a search query based on the activity, e.g. “Instapaper.” This logic is based on some open source code I wrote for Riposte, available on GitHub.
With the exception of Pocket, all third-party services in OvershareKit support multiple accounts. We included an account management screen that you can use to add or remove accounts for each service. You can see the accounts screen in the sample app by tapping the left navigation bar button from the app’s main screen. You’ll know best where this screen should live in your application.
VoiceOver and Localization
OvershareKit’s views and alerts have 100-percent VoiceOver coverage. All user-facing strings are in English, but you can provide localizations via the localizationDelegate of OSKPresentationManager. Never ship an app without VoiceOver, and never ship a new design without testing its accessibility implications first. Ask your users for help. You probably already have some tech-savvy users with visual or other impairments that would love to join your beta team. Look for smart folks like Marco Zehe and Steven Aquino.
Dave Brasgalla has an interesting write-up on the iconography of the first Alien film and its parallels to the iconography of iOS 7. In the course of his article, he offers his take on iOS 7:
For my part, I have a very positive feeling towards iOS 7, for one main reason: it brings computer iconography firmly back around to concentrating on communication rather than illustration – function over form. This is the realm of the graphic designer, where informed decisions about composition and colour create successful, strong symbology that will outlast trends, and is applicable over multiple uses.
I think everything he writes makes sense, but I also think what he says is totally irrelevant to why most people buy and enjoy iPhones and iPads.
People don’t choose an iOS device out of respect for Apple’s adherence to formal design principles. They are only dimly aware, if at all, of the design battles being waged between people who make apps and smartphones for a living. People buy iPhones and iPads because they are the first computers that you can use without feeling stupid.
The warm, evocative design of iOS 1 through 6 made using a computer easy and fun. For many, many people, this was an entirely novel experience. Most people had only ever owned or used clunky, complicated Windows PCs for work or school. It was walking on egg shells, and it was never fun. The iPhone changed all that.
Designers with more rarified tastes may cringe at torn paper textures and green felt, but these extremes were the exceptions, not the norm. This bears repeating: the skeuomorphic excesses of iOS 1-6 were the exception, not the norm. The norm was much more nuanced. The aesthetics were focused on making things intuitive and fun:
Notes.app Icon: On iOS 6, the Notes.app icon was a little roundrect version of a yellow legal pad. It was warm, cute, and — most importantly — easy to understand. It immediately conveyed its purpose: this is for jotting down notes. The new icon looks like nothing at all. It has been designed with strict adherence to Apple’s new formal visual rules for their app icons, but only against that metric could it be called a success. The new icon puts form before function.
Buttons: On iOS 6, buttons had subtle gradients and borders, not as whizz-bang, but to make it abundantly clear where you were being invited to tap — just as sidewalks make it abundantly clear where you are being invited to walk. On iOS 7, it is often impossible to tell what is a button and what is not.
Slide-to-Unlock: On iOS 1-6, the lock screen slider was composed of a sliding button and a track. It was so easy to understand that babies literally figured it out on their own. The springy physics were reminiscent of the spring-loaded locks on gym locker doors, which helped both convey the slider’s purpose and how to use it. On iOS 7, the obvious slider has been replaced by a tiny chevron on de-valued visual footing against many similarly-colored elements. There is no visual affordance for how the unlock gesture is supposed to work. The “slide to unlock” text label is still there, but a) it doesn’t specify what or where you are supposed to slide, and b) is so thin and glittery that it is often impossible to read. Try starting a turn-by-turn Maps.app session and then look at your lock screen. It’s incomprehensible.
We’ve all heard the old design adage that “form follows function.” Those of us who make apps for a living have heard it so many times that it’s easy to ignore it as trite. In reality it is very difficult to adhere to that principle. It is difficult because separating form from function is a messy exercise. It must be done delicately, and with respect for what our users think and feel.
On iOS, putting function before form is not as simple as paring down icons to a strict grid and color palette. There are functions beyond literal communication that iOS designers must balance. Making icons warm and inviting serves many deeper purposes. It builds your confidence in the device. It makes you feel in control. It sets your mind and thumbs at ease. It communicates through feeling and memory, and when done well, resonates with human experience in a way that PCs never could.
What is Overshare? It’s the answer to the pit I felt in my stomach when I contemplated writing sharing code all over again for Unread. Sharing is so common, and so important, yet there’s no library out there that covers both the easy and complex cases gracefully.
Overshare makes it trivial to add rich sharing options to your iOS apps. In a word, Overshare has everything:
Beautiful share sheets with pixel-perfect, full-color icons in a simple layout.
Lots of tweakable options, including a gorgeous dark mode.
Built-in integration with iOS Twitter and Facebook accounts.
Built-in integration with popular third-party services like App.net, Instapaper, and more.
Complete multi-account management, including authentication and storing credentials securely in the Keychain.
Killer text editing views with as-you-type Twitter syntax highlighting, Riposte-style swipe gesture cursor navigation, and automatic smart quotes.
URL scheme integration with 1Password, OmniFocus, and Things.
Head on over to the Overshare GitHub account and check it out!
Overshare will be shipping in the 1.0 of Unread, and will likely find its way into Riposte and Whisper, too. If you’re so inclined, we’d love for you to test Overshare in your development apps and let us know how it goes.
I dislike iOS 7 so strongly that I feel inclined to begin this post with a disclaimer about how much I admire Apple. Apple is my hero. They’ve always inspired me to be better at what I do, even when I was an ICU nurse. But they are not perfect. I can and should criticize their worst work when I find it — out of my admiration for their best work.
To understand the biggest design mistake Apple made in iOS 7, you have to acknowledge a fact so obvious that it can be easily overlooked: touch. The essential characteristic of iOS is touch. Skin against glass. A round, squishy, inaccurate little fat pad at the end of your finger. Unlike the PCs that iOS devices replaced, everything you do on iOS is driven by your thumb pressed directly against the screen. There is no intermediary device. Simply put, the importance of touch on iOS cannot be overstated.
Good iOS app design is obsessed with touch. Bad iOS app design takes touch for granted. We’ve all seen apps that look like they were designed by talented print designers, apps with beautiful screenshots and tasteful typography that nevertheless fall apart disgracefully as soon as you actually try to use them. These apps don’t fail for lack of talent. They fail because their designers have the wrong process. They’re beginning with aesthetics and squeezing in the interactions wherever they have room to fit. The right process moves in the opposite direction. A good iOS app designer begins with touch, and only afterwards chooses aesthetics that complement and enhance the underlying touchable structure. iOS 7 has been designed with the wrong process.
What makes something touchable?
For things that scroll or zoom, touchability means that the content under your finger moves with your touch, without any lag or jitters. iOS 7 does as good a job with this as with previous iOS versions. In some cases it does it even better, as in the new swipe-to-go-back gesture in apps like Safari and Mail, or the bouncy physics that you can see when swiping up the Control Center.
For buttons, touchability requires something different. Touchable buttons need borders. By “borders” I don’t mean outlines, (although outlines are included in my usage of the word). I mean borders in a broader sense. A button is a tappable area, clearly delineated from the un-tappable content around it by an obvious border.
Borders around buttons can be real or implied. A real border is like the roundrect shape around a “Buy” button on the App Store. An implied border is like those around the toolbar icons at the bottom of the Safari screen.
Implied borders are easy to get wrong. Care must be taken to make sure that aesthetic choices don’t obscure where one button ends and another begins. This is why iOS app designers make all toolbar icons fit into a roughly square shape. When set together in a row, adequately spaced, the eye can perceive the 44-by-44 point implied border around each button.
iOS 7’s designers have abandoned bordered buttons in favor of borderless colored text. I think this choice is unjustifiable. It is the root cause of my deep dislike for how it feels to use iOS 7. It introduces unnecessary tension and makes everything less usable than it ought to be.
Color alone simply cannot be the way to identify a button. You don’t touch a color. You touch an area. To activate a button, you must touch a spot inside of its boundary. Text floating in the middle of vast whitespace doesn’t define a boundary. Only borders define boundaries.
Compare the navigation bar buttons from the native Twitter share sheet with those from Tweetbot’s navigation bar:
In the iOS 7 share sheet, there are three text labels: Cancel, Twitter, and Post. Which of these three are buttons and which ones are not? Those of us who are lucky enough to have good vision might correctly guess that the blue ones are buttons, but what if we were color blind? Furthermore, how do we know whether or not the title doubles as a tappable button, like the title button in Tweetbot that can be used to toggle the source list?
The Tweetbot title button is obvious because it’s enclosed by obvious borders. If Tweetbot were redesigned to strictly adhere to the iOS 7 paradigm, it would be impossible to know whether or not the title was tappable. What if this fictional Tweetbot made the title blue also. Wouldn’t that actually make it harder to distinguish buttons from inert labels?
There are many other examples in iOS 7 of how the lack of borders creates a dizzying confusion. The Contacts app is a particularly strong example:
How do we know that “John” and “Appleseed” are editable? They’re not blue. They’re black, borderless, and floating some inscrutable distance from one another and from the other elements above and below them. How do we know that they are separate text fields, and not one big multiline text view? Is “Company” editable? If so, where does it’s tappable region end and the “add phone” area begin? Likewise, what about the empty region between “add phone” and “add email”? Are the cell separator lines defining a tappable boundary around the “add email” row? You’d be forgiven for assuming so, since those lines create the impression of a tall tappable row, but you’d be wrong.
I imagine that folks might argue that web page links are examples of buttons made solely from colored text. Aren’t people already familiar enough with links on the web that using the same paradigm on iOS is a simple change?
My counterargument is that web links are subject to the same visual risks as native buttons on iOS. Links can be just as confusing if not treated carefully. Links that use not only a different color but also some other means of differentiation, like a heavier font weight or an underline, are easier to use than links based on color alone. This is why Mobile Safari paints a dark grey roundrect over a link’s tap boundary when it’s pressed. It makes it explicit exactly which link you’ve tapped:
Apple’s goal of refining iOS down to its essential elements is a noble one. The video that they played again at the October Event yesterday is full of inspiring ideas. Unfortunately, much of iOS 7 suffers from an overzealous fixation on the reduction of visual flourish, ignoring the deeper functional roles that the previous visual effects performed. Buttons don’t have to be made from green felt or stitched leather, but they still need to look like buttons.
Horace Dediu once said, of the idea of a business disrupting itself, “You have to be completely psychotic about it.”
The same is true of creative work. Hate the past. Scrutinize the present. Obsess over the future.
I spent a few years of my life pursuing a theology degree. It didn’t stick, but if there’s one thing I’ve kept from my churchy upbringing, it’s the concept of Christian Perfection. For John Wesley, the founder of the Methodist church, being good enough isn’t good enough. Perfection is the only good worth seeking. Wesley was batshit crazy, but he was profoundly influential on the people his life touched.
Perfection, for Wesley, isn’t possible. Yet it is the constant goal towards which good people strive just the same. Good works are done, one gets closer to perfection, but never close enough. There are victories along the way. With each victory, the temptation is to become enraptured by one’s own successes. The dangerous irony here is that being a better person is itself the source of the temptation that can ruin it all. Pride cometh…
As creative workers, we have to learn how to do our best every day as if for the first time, forgetting what we did before as if it was someone else’s success and not our own.
If you are a revolutionary technology company, or a film production company with a perfect track record, or a preeminent blogger, then goddammit you had better be goddamn perfect, and that means perpetually acknowledging how far you have left to go.
Remember how quick Steve Jobs was to dismiss his past successes?
I’ll close this with the best words Wesley ever wrote (and he filled many volumes before he died; emphasis added):
Fire is the symbol of love; and the love of God is the principle and the end of all our good works. But truth surpasses figure; and the fire of divine love has this advantage over material fire, that it can re-ascend to its source, and raise thither with it all the good works which it produces. And by this means it prevents their being corrupted by pride, vanity, or any evil mixture. But this cannot be done otherwise than by making these good works in a spiritual manner die in God, by a deep gratitude, which plunges the soul in him as in an abyss, with all that it is, and all the grace and works for which it is indebted to him; a gratitude, whereby the soul seems to empty itself of them, that they may return to their source, as rivers seem willing to empty themselves, when they pour themselves with all their waters into the sea.
Instagram released their iOS 7 update today. I’m sorry to report that it is not good.
The previous Instagram interface embodied the ideal iOS app design. It had oodles of personality while still retaining a mass-market appeal. There was a consistent set of styles applied to every screen, in a palette that was restrained, yet identifiably Instagram.
Today’s update is a mess. It’s awash with stylistic contradictions, as if their designers were caught between a desire to kowtow to Apple’s new guidelines and their own internally-cultivated sense of taste.
The app icon is still the realistically-detailed little camera we’ve all grown accustomed to, suggesting that the rest of the app hasn’t changed, when in fact the opposite is true.
The navigation bar has been reduced to a flat Instagram blue, dropping all of the tiny details from the previous version. Strangely, the navigation bar is only blue on the main timeline. All the other screens use a system-default, blurred-white navigation bar. Swiping back from a detail screen into the main timeline creates some extreme disharmony as the status bar disappears on one half of the display.
Making matters worse, the status bar animates in a harsh manner from white-on-blue to black-on-white when you scroll down into your timeline. To be fair, this is as much Apple’s fault as Instagram’s for creating the problem in the first place. Instagram’s poor solution is a great example of why apps shouldn’t have to accomodate an overlapping status bar. The iOS 6 plain black status bar is still the best solution for most cases.
Square avatars have been replaced with circular ones, which have long since lapsed from cool to trendy to tacky. John Gruber makes a great observation about them:
And for Instagram in particular, it breaks a certain elegance — your avatar was the same thing as a post, a square image.
The camera interface is almost unchanged from the iOS 6 version, except for the removal of the subtle noise that provided texture for the large grey toolbar areas. Buttons have borders, shadows, and soft bevels (and they look great). The contrast between the stylized camera screens and the flat default look of the rest of the app is the most troublesome contradiction. As my friend Preshit Deorukhakar said on App.net:
Did Instagram designers forget there’s a Camera View in the app when designing the iOS 7 update?
Tim Van Damme, the primary designer of the iOS 6 interface, left Instagram this summer for Dropbox. I have no idea how much he was involved in the iOS 7 redesign. As an outside observer, the portions of Van Damme’s work still visible in the app look like splotches of blue-grey on a half-finished whitewashed wall. The spirit and unity of his work is gone. Those picking up where he left off need to either fully commit to the new flat style, or else strike out on a bolder tack. Half-assing a push into two contradictory directions at once is a sure way of getting lost in the weeds.
The New York Times posted a fascinating and heartbreaking mini-documentary on thalidomide. Once a popular and useful medication, thalidomide became infamous for the severe physical birth defects it causes when taken by pregnant women. You may have heard of this drug. What you might not know is that it is still manufactured for limited use in the treatment of several conditions, including leprosy.
Before making apps and before working as an ICU nurse, I worked as a pharmacy technician at a small town pharmacy. We carried thalidomide, if I recall correctly. Drugs like thalidomide (or Accutane, a commonly-prescribed acne medication with similar risks of devastating birth defects) are dispensed with extreme caution, even in a small town pharmacy. There’s a mind-boggling amount of paperwork and patient education every time someone is prescribed one of these drugs.
Not all drugs are this dangerous, but it’s still a good idea to understand any drugs you take regularly. Don’t hesitate to visit your pharmacist and ask her questions.
Pro tip: ask your pharmacist for one of the manufacturer’s drug information pamphlets — not the consumer pamphlets, but the richly-detailed ones that are printed on thin white paper, folded into stout squares, and glued to the backs of medical-grade drug packaging. The pharmacy probably throws most of these in the trash anyway. They have great summaries of the side effects seen during clinical trials, including comments on which ones were most frequently reported. Much of it is readable to a layperson, if you’re determined to learn something. You can see one in this photo, taped to the top of the small amoxicillin bottle.
Another pro tip: only capitalize brand names for drugs. Generic names should be set in lowercase.
New versions of Riposte and Whisper are coming out today, coinciding with the launch of iOS 7, Apple’s beleaguered new operating system. Jamin and I are really excited about both our app updates. They were harder to accomplish than they might appear. Here are some of the hard problems we had to solve while redesigning them for iOS 7.
Riposte’s Freshened-up Timeline
Riposte is largely the same, visually. We were fortunate that our minimal approach to user interface chrome worked to our benefit during this update. The familiar flat white posts, with simple hovering buttons are still there. Swipe-to-go-back is still there. The text is laid out more accurately now, and with a little more breathing room padding each post. This makes it easier to scan a busy timeline without needing heavy borders or gradients.
The coolest visual change to Riposte is the redesigned flip animation when you tap a post:
It’s more at home on iOS 7 with its added depth and subtle bounciness. More importantly, it solves one of our oldest problems. App.net has long posts, made even longer by our decision to present image attachments in large thumbnails that span the screen. The old animation style flipped the entire cell over, which looked pretty silly when flipping a long post. This new animation partially tilts the cell in from the bottom, so that the buttons are always accessible from the top of the post, no matter how long it is. It uses the new UIMotionEffects APIs, too. You can see them by tilting your device around in your hand after opening a post.
Our users love upgrading to Riposte Pro so they can customize their fonts. Every bit of text looks better on iOS 7, especially in the minor elements like buttons and settings labels. Riposte Pro users can now choose separate fonts for author names and body text for their timelines, with two additional typefaces for the former: Helvetica Neue Condensed Bold, and Avenir Next Condensed Bold. These look really good when set at one the two new enormous font sizes: “Biblical” and “Bruckheimer.”
Speaking of Helvetica Neue Condensed Bold: it’s now doing double-duty as the default Riposte font for navigation bar titles and back buttons. Apple’s redesign of the back button to use wide, borderless text instead of the familiar pointed roundrect leads to frequent overlapping between the back button text and the navigation bar title when using standard UI fonts. It’s sometimes impossible to distinguish the two from each other, especially for color-impaired users.
Our new navigation bar typography.
The solution I used in Riposte was switch to a condensed version of Helvetica Neue, which helps maintain a breezy margin between the titles and back buttons of navigation bars. Its sturdy precision introduces a different emotion, but in a way that makes Riposte Version 1.5 feel new, like a new Swiss Army Knife still in the box.
Riposte now highlights mentions, hashtags, and URLs as you type. If you upgrade to Riposte Pro, you can also use Markdown syntax to write custom links.
The syntax highlighting was made easier by one of my favorite new iOS 7 APIs, the
NSTextStorageDelegate protocol. Every UITextView has a new
textStorage property. Set your custom class as its delegate and implement the following delegate method to make edits to text and color attributes after the user types them, but before they’re committed to the display:
- (void)textStorage:(NSTextStorage *)textStorage willProcessEditing:(NSTextStorageEditActions)editedMask range:(NSRange)editedRange changeInLength:(NSInteger)delta NS_AVAILABLE_IOS(7_0);
It’s the perfect spot to replace dumb quotes with smart quotes, too.
People hate having gaps peppered throughout their timelines in Riposte. Jamin wired up Riposte and Whisper to take full advantage of the new background updating APIs available with iOS 7. They’ll update themselves after any push notification, and at any other time the OS thinks will help. The end result is that you can say goodbye to timeline gaps and stale conversations. New posts and messages will be there waiting for you.
Status Bar Challenges
Apple threw us all a curve ball when they redesigned the system status bar for iOS 7. I wrote about the technical implications yesterday, but there are huge design implications, too.
For years, the status bar had been made a subtle extension of the hardware, quietly separated from an app’s interface. Now it overlaps all apps by default, without any background color. Apple has capriciously left the repercussions of this decision up to each app designer to sort out on her own. We’re probably going to see as many bad solutions as good ones as app updates roll out on the App Store over the coming weeks.
The new paradigm in Apple’s own apps is to make the navigation bar background blend seamlessly into the status bar background. Neither Riposte or Whisper use navigation bars consistently, so this wasn’t an option for us. Some screens (Settings modals, New Posts, et cetera) have navigation bars, but the majority of the time our apps are full screen and nearly chrome-less. Furthermore, both apps have transient notifications and toolbars that show and hide from the top of the screen. It would have been a technical nightmare to keep these interactions consistent across all our app’s screens, making sure that all scrollable content isn’t obscured and that allowances are made for those times that navigation bars and status bars change their visibility states.
In our opinion, the iOS 6 plain black status bar is still the best solution for our users. We had to fake it with some clever changes, but it will look and behave the same in Riposte and Whisper for iOS 7 as it did on iOS 6.
Whisper Pressed Between Microscope Slides
Whisper’s visual style has been dramatically scaled-down for iOS 7. It isn’t completely flat, though. It’s more like the old Whisper has been sandwiched between microscope slides. Look closely at the new message bubbles and you’ll see that they’re subtly demarcated with top highlights and inner bottom shadows, giving the subtlest hint of depth. Borders and gradients have been drastically reduced, too, yet not eliminated.
The rationale for the Whisper redesign is, in a word, the keyboard. The system keyboard occupies half of your screen when you’re chatting with friends. Just as the iOS 6 version of Whisper borrowed color and visual cues from its keyboard, so does the iOS 7 version. Lines are thinner and shapes are less bulky, in keeping with the rice-paper-thin keyboard buttons.
We also added some fun new stickers, too, to thank our hard-working beta testers. Every tester was asked to pick a new sticker design that they wanted to have for themselves, no matter how bizarre. See if you can guess which stickers belong to whom:
Everything is Fine, Everything is Ruined
For every new API released with iOS 7, there were a dozen existing APIs that were either deprecated or downright broken. I would estimate that 90 percent of the work that went into these two updates was just getting all the broken features up and running again. A complete list of such things would be too tedious, but here’s a taste:
- Text views are now prone to leaving fragments of text after large cut & paste edits are made, under certain circumstances. This meant rewriting significant portions of the logic that lets you pull down to see the replied-to-post when writing a reply in Riposte.
- The lines between the main menu cells had to be drawn by hand, instead of using the default separator lines (including the logic to hide the lines from adjacent cells when selecting a row, ugh) because of a bug in UITableView.
- Keyboard animation changes required a major rewrite of the way Riposte and Whisper adjust toolbars and buttons while you’re writing private messages. What was already some of the most complex code in both apps is now even more complex.
- The status bar. Enough said.
You can download the latest versions of Riposte and Whisper from the App Store today, as soon as Apple flips the switch and makes them available.
While updating Riposte and Whisper for iOS 7, one of the recurring problems I had was getting our view hierarchy to layout correctly. The most troublesome APIs are those for the system status bar and UINavigationController. The API documentation is woefully inadequate as of this writing. The following is, to the best of my knowledge, essential information for any developer struggling with status bars and view controller containment on iOS 7:
There is no way to preserve the iOS 6 style status bar layout. The status bar will always overlap your application on iOS 7.
Do not confuse status bar appearance with status bar layout. The appearance (light or default) does not affect how the status bar is laid out (frame/height/overlap). It is important to note as well that the system status bar no longer has any background color. When the API refers to
UIStatusBarStyleLightContent, they mean white text on a clear background.
UIStatusBarStyleDefaultis black text on a clear background.
Status bar appearance is controlled along one of two mutually-exclusive basis paths: you can either set them programmatically in the traditional manner, or UIKit will update the appearance for you based on some new properties of UIViewController. The latter option is on by default. Check your app’s plist value for “ViewController-Based Status Bar Appearance” to see which one you’re using. If you set this value to YES, every top-level view controller in your app (other than a standard UIKit container view controller) needs to override
preferredStatusBarStyle, returning either the default or the light style. If you edit the plist value to NO, then you can manage the status bar appearance using the familiar UIApplication methods.
UINavigationController will alter the height of its UINavigationBar to either 44 points or 64 points, depending on a rather strange and undocumented set of constraints. If the UINavigationController detects that the top of its view’s frame is visually contiguous with its UIWindow’s top, then it draws its navigation bar with a height of 64 points. If its view’s top is not contiguous with the UIWindow’s top (even if off by only one point), then it draws its navigation bar in the “traditional” way with a height of 44 points. This logic is performed by UINavigationController even if it is several children down inside the view controller hierarchy of your application. There is no way to prevent this behavior.
If you supply a custom navigation bar background image that is only 44 points (88 pixels) tall, and the UINavigationController’s view’s bounds matches the UIWindow’s bounds (as discussed in #4), the UINavigationController will draw your image in the frame
(0,20,320,44), leaving 20 points of opaque black space above your custom image. This may confuse you into thinking you are a clever developer who bypassed rule #1, but you are mistaken. The navigation bar is still 64 points tall. Embedding a UINavigationController in a slide-to-reveal style view hierarchy makes this abundantly clear.
Beware of the confusingly-named
edgesForExtendedLayoutproperty of UIViewController. Adjusting
edgesForExtendedLayoutdoes nothing in most cases. The only way UIKit uses this property is if you add a view controller to a UINavigationController, then the UINavigationController uses
edgesForExtendedLayoutto determine whether or not its child view controller should be visible underneath the navigation bar / status bar area. Setting
edgesForExtendedLayouton the UINavigationController itself does nothing to alter whether or not the UINavigationController has a 44 or 64 point high navigation bar area. See #4 for that logic. Similar layout logic applies to the bottom of your view when using a toolbar or UITabBarController.
If all you are trying to do is prevent your custom child view controller from underlapping the navigation bar when inside a UINavigationController, then set
UIRectEdgeNone(or at least a mask that excludes
UIRectEdgeTop). Set this value as early as possible in the life cycle of your view controller.
UINavigationController and UITabBarController will also try to pad the contentInsets of table views and collection views in its subview hierarchy. It does this in a manner similar to the status bar logic from #4. There is a programmatic way of preventing this, by setting
NOfor your table views and collection views (it defaults to
YES). This posed some serious problems for Whisper and Riposte, since we use
contentInsetadjustments to control the layout of table views in response to toolbar and keyboard movements.
To reiterate: there is no way to return to iOS 6 style status bar layout logic. In order to approximate this, you have to move all the view controllers of your app into a container view that is offset by 20 points from the top of the screen, leaving an intentionally black view behind the status bar to simulate the old appearance. This is the method we ended up using in Riposte and Whisper.
Apple is pushing very hard to ensure that you don’t try to do #9. They want us to redesign all our apps to underlap the status bar. There are many cogent arguments, however, for both user experience and technical reasons, why this is not always a good idea. You should do what is best for your users and not simply follow the whimsy of the platform.
Accompanying Stack Overflow answer available here.
Horace Dediu from an interview posted this morning (emphasis added):
An internet business is the arbitrageur who takes advantage of the inability of each market to price the other. History shows that arbitrage markets tend not be stable as information begins to leak across markets. Therefore what would blow the internet up is if consumers could become wiser about what they are giving up and advertisers would become wiser about aggregating consumer data. I imagine a system where each individual would allow bids on their consumption and a market mechanism where bidders competed for that data. This of course depends on users taking control and ownership of their own data.
It would create a new era which will have political dimensions. I imagine we’ll need an internet citizen’s bill of rights or some such movement which will reset expectations. Economically, could bode well for those who position themselves as protectors of the individuals and be a crisis for those who take advantage of consumer ignorance.
Note that this would be a structural difference, not a difference of technological capability. In other words, Facebook, Twitter, and Google could not copy it without destroying their established businesses. Isaac would have to sacrifice Abraham.
Jordan Cooper (a.k.a @blenderhead on App.net) invited Jamin Guy and I to his podcast this week to talk about the future of App.net, embarrassing oneself in eighth grade history class, offending family and friends with demonstrably funny jokes, location-aware apps for pot enthusiasts, and more.
Depending on whom you ask, iOS 7 is either a hero or a villain. It’s a spring-cleaning of the cobwebs from an outdated visual style, or it’s an over-correction based on an inflexible system of dubious rules. It’s Apple once again breaking free from the constraints of the past, or it’s Apple showing up unfashionably late to the newest fad.
These opinions can’t all be right, but can any opinion be right? How will we know when iOS 7 can be judged a success or a failure? What does “success” even mean for an iOS update? What role does interface design play in this success?
A good place to start is with Apple’s own attempts to draw an outline around iOS’ impact on the mobile OS landscape. In this years’ WWDC Keynote (beginning around 69:40), Tim Cook approached iOS from several angles: install base, usage, and customer satisfaction.
If success is defined by the percentage of in-use devices that are updated to the latest OS, then iOS 7 is probably going to be the most successful iOS version to date. According to Cook, ninety-three percent of iOS devices are using iOS 6 (with six percent running iOS 5). This is most likely a testament to the ease of installing over-the-air software updates, as well as Apple’s efforts to support older devices still in widespread use. These factors are not changing in iOS 7, so I would expect to see similar numbers at next year’s Keynote.1
iOS device owners use their devices more often than other mobile device owners. According to Experian, iOS devices are used 75 minutes a day, on average, compared to 45 minutes a day for Android.2 If these usage times tip in favor of Android, it could mean that the changes in iOS 7’s design are making customers less willing to spend time with their devices. This seems an unlikely scenario to me. The “offensive” changes in iOS 7 are mostly superficial. The key differences between iOS and Android devices3 — tight integration of hardware and software, the richness of third-party apps, etc. — won’t change from iOS 6 to iOS 7.4
The primary metric that Apple uses to objectively measure iOS’ success is customer satisfaction scores — or “customer sat” as Cook referred to it during the Keynote. He proudly noted that the iPhone has been ranked number one in customer satisfaction by J.D. Power nine consecutive times — a first for any product. ChangeWave found that overall satisfaction was 97 percent for iOS device owners, and that 73 percent of them characterized themselves as “very satisfied.”
Of all the metrics used to measure iOS’ success, I think that customer satisfaction is the one to watch most closely. If customers find something distasteful about iOS 7, I would expect to see a drop in both overall satisfaction and in the number of people who claim to be very satisfied. Or perhaps the opposite might happen. Either way, customer satisfaction is the best measure we have. The other metrics compare iOS to Android and other mobile operating systems. The data are influenced by too many external factors to be a good measure of the iOS 7 user experience itself.
Another measure of success will take longer to notice. Over the next two or three years, as contracts begin to expire and customers head out in search of device upgrades, what kind of devices will they choose? Will iOS sales growth taper off as customers choose alternatives?
Standing in an AT&T store recently, the only smartphone in the store that didn’t have a “flat” design aesthetic was the iPhone. Windows Phone’s app tiles swooped around in a delightful way, with no drop shadows or gradients to distract me. The Android lock screens were hard to distinguish from the iOS 7 test device I’d brought with me in my pocket. The build quality of some of the Samsung, HTC, and Nokia phones was comparable to the iPhone. Their screens were bigger and more pixel-dense. The HTC One felt more like a miniature iMac then a smartphone. It felt great to heft it around. Standing there, absorbing all of the options available to me, and with AT&T staff more than happy to sell me an Android device as easily as an iPhone, I wondered why anyone chooses an iPhone at all.
If the appeal of the iPhone, all the years it’s been on sale, is in part due to the little visual details — a notepad icon that looks like what it does, an unlock slider so easy to grasp than even babies figure it out on their own — then iOS 7 could be spoiling the key ingredient to the success of its predecessors. Time will tell.
- There are still a lot of iPhone 3GS devices in use, which will not be supported by iOS 7. However, with the steady growth in the smartphone market overall, and the likely introduction of lower-cost iPhone models in the fall, I expect that by June 2014 any impact on the iOS 7 install base by iPhone 3GS devices running iOS 6 will be more than compensated for by sales of newer iOS devices. ↩
- That’s a time difference of only thirty minutes. Since iOS devices are generally more power-efficient than their Android counterparts, it is not implausible that the Android deficit is a side-effect of battery life. If Android devices with better power-consumption are released, then Android usage numbers could improve without implying anything negative about iOS 7. ↩
- Some people argue that there are also differences between iOS and Android device *owners*. I won’t make such an assumption here. If there is any truth to this notion, it could plausibly account for usage differences, too. But if personality drives usage, then iOS 7 isn’t going change anything. A software update can’t make you a thinner, overzealous bore. ↩
- Cook also presented data on mobile web usage on tablets, but these data also aren’t likely to change with iOS 7, since the underlying causes will remain the same. ↩
My internet pal Shawn Blanc has released a new book today: Delight is in the Details, a book for craftspeople about the practice of sweating the small stuff. The exhortation from the announcement email was great:
Now, go forth and make something delightful.
Spoken like a true Protestant. I look forward to reading his book this week.