My driving principal while designing RECaf was to make the app “thumb-able.” That is, I wanted to be able to do as many tasks as possible with the phone in one hand, gesturing only with my thumb.

This is getting harder with every new iPhone generation.

Years ago, Jeff Hawkins, creator of the original Palm Pilot and then CEO of Handspring, commented on the one-hand-ability of the Treo line of smart phones. He was getting asked frequently why Handspring had adopted plastic RIM-style keyboards on its phones, rather than relying on the Graffiti handwriting recognition he had pioneered for Palm devices.

“I think the most important thing here is that on a phone, you have to have a keyboard. You really want to have one-handed operation, and that requires a keyboard....”^[1]

This was a few years before Apple released an on-screen touch keyboard that anyone would consider usable, of course. The point is, in Hawkins’ mind, any task you needed two hands to do on a mobile phone was a failure, at least to some degree. The task may be easier or better to do with two hands, but it needs to be possible with one hand. I believe this is still largely true.

We’re busy people, and our hands are often busy throughout the day. When I’m walking around the city, I’m often lucky to have one hand free to pull out my phone and get something done. The last thing I want is to have to free up the other hand just to do the simplest of tasks.

Unfortunately, phone manufacturers and software developers have all but thrown the one-hand principle out the window in recent years. The allure of larger and larger screens has decreased the thumb-reachable percentage of the screen significantly. And yet, much of our software, particularly on iOS, has failed to accommodate.^[2]

When the first iPhone was released, with its puny 3.5-inch screen, I could easily reach every corner with either thumb. On an iPhone XS Max, with its gargantuan 6.5-inch screen, I’m lucky to reach even 60% of the total screen area without a second hand. And yet, Navigation bars, with their all-important Cancel and Done buttons, and many other controls are still located at the top of the screen, way out of thumb’s reach.^[3]

And it’s not just the top of the screen. The larger your screen area, the more difficult it becomes to carefully balance the device and reach the bottom of the screen as well. Simply moving navigation to the bottom of iOS would not adequately address this issue.

With this in mind, I approached RECaf’s design as if my thumb were the only option for at least the most common actions^[4]. If it was something I needed to do more than occasionally, and I couldn’t do it with my thumb without some sort of awkward phone juggling, I declared the design a failure and started over.

Throughout the process, I studied other apps that had tackled this issue—some built-in from Apple, others from third parties—and I adapted what I considered to be the best ideas from each.

The Tab Bar

I’m not a big user of Snapchat (I’m not in the correct demographic) but when a few developers I trust showed me Snapchat’s swipe-able tabbed interface, I knew a variation of that would be perfect for RECaf.

The Tab Bar lives at the bottom of the screen, so technically, it is reachable by the thumb. But I find it so much easier to simply swipe between tabs vs reaching down to the bottom of the screen and tapping that frankly I would love it if Apple stole this idea for the standard Tab Bar.

Since this is not a standard implementation, of course, it took a bit of work to get the animations and the gestures working as well as I liked. But the end result is so fluid and simple. While a more complex tabbed interface with more tabs and deeper navigation structures might make this impractical, in RECaf’s case, with only three tabs, it’s perfect. With the easiest flick of your thumb, you can get from one major area of the app to another. You can still tap on the icons on the bottom toolbar as well, of course, if you are unaware of the swipe gesture.

Drag-able Panes

Over time, Apple has been adding drag-able panes to Maps and other built-in apps, such as Stocks; a variation of the same pattern also exists in the current Music app. And many third-party apps have copied and enhanced this pattern themselves, most notably ride-sharing apps like Lyft. The idea is to put information in a panel, or pane, that can be dragged up or down to reveal more information/controls on two different z-depths. This way, you get almost two screens worth of UI on a single screen, and you can move the information you don’t want out of the way with a simple thumb movement up or down as needed. Put a scroll view inside these panes, and you can get just about any active controls you need under your thumb with relative ease.

In RECaf-this became the perfect way to show both a listing of historical statistics about your caffeine habits and a listing of your entire caffeine logging history on the same screen. Just tap, swipe, or drag the All Log Entries pane up, and the history is concealed behind the long list of entires. Drag, swipe, or tap it back down, and the stats become visible again.

A more complex variation appears on the Log Entry screen, where you can move two different panes (frequents and favorites) to show three different methods of logging on a single screen (frequents, favorites, or custom). Rather than putting these three modes behind a segmented control, having to tap all the way on the top of the navigation bar to switch modes, you can simply move your thumb up or down to reveal the UI you need. Because the panes are drag-able from any visible part of the pane, it doesn’t matter how precise you are about the dragging, either. Wherever your thumb happens to land on the pane, you can move it up or down. You can even move both panes at once, so you’re never more than one drag away from he UI you need.

The podcast app Castro uses a similar approach with its now-playing screen. You can swipe down from just about anywhere on the now-playing screen to go back to the main interface.

Implementing this in RECaf took quite a bit of UIPanGestureRecognizer gymnastics (and ample use of container views) to get it working smoothly, but at the end of the day, I ended up with an extremely “thumb-able” UI. Given how often Apple is using a similar pattern to avoid putting UI tools in navigation bars in Maps and other built-in apps, I wouldn’t be surprised at all to see drag-able panes become a much more common part of iOS in the future. That would make me very happy. I’d love to have an official API for creating such interfaces, rather than the custom implementations many of us have had to create in the meantime.

Viewable Content vs Interactive Regions

Clearly, we can’t put our entire interfaces under our thumbs. We have these gorgeous giant screens; we want to use every pixel. But if you reserve the areas that are out of reach of your thumb for visual information that isn’t interactive, you can free up the thumb-reachable region for your interactive elements.^[5]

In RECaf, I wanted to take advantage of the larger screens of some iOS devices by putting the pertinent information, whenever possible, above my thumb. On the source detail page, for instance, the name, icon, and other information about the source is listed just below the navigation bar, while the interactive buttons for favoriting amounts and adding Siri Shortcuts are placed in the thumb zone.^[6]

By all means, we should make use of every pixel of our screens. We just have to be sure the parts with which we need to interact are not out of reach.

Conclusion

Large screens on phones are not going away anytime soon. At the same time, our thumbs aren’t going to magically start getting longer. That shrinking percentage of reachable screen real-estate needs to become the focus of interactivity, while the outer regions of the screen are devoted mainly to information display. The more designers and developers consider this, the better time we will all have with our apps, regardless of our screen-size preferences. I hope Apple, too, is planning on leading us in this direction with future versions of iOS.

Okay: Crazy designer ideas time. Bear with me. This is not a prediction of what may or may not happen at tomorrow’s Apple event. Just a thought that’s been rattling in my brain for the past few months.

Have an iPad handy? Great. If not, use your imagination.

Pick up the iPad and hold it as you normally would in landscape orientation. Where are your hands? If you’re anything like me, one of your thumbs is roughly on top of the home button, and the other one is just about covering the selfie camera. Hands are basically in the middle of the device, in other words.

Now, hold the iPad in portrait mode. Where are your hands? Chances are, your hands are towards the bottom of the device, not the middle. Your thumbs are not covering the center of either long side of the device.

Is it me, or is this an argument for Apple putting the Face ID sensor array on one of the longer, landscape sides of the device?

Now, there may be some perfectly logistical, engineering reason why the selfie cam/sensor array needs to stay on the short side of the device. This is why I’m not making any predictions here. But if it isn’t physically difficult or impossible to put the array on the longer side, I think Apple would and should put it there. Otherwise, forget whether or not Face ID can work in landscape or portrait. We may have to take one hand off the device every time we need to authenticate when we are holding in landscape, anyway. Which would not be ideal.

Ever since the 10.5-inch iPad Pro was released, with it’s slightly longer aspect ratio, I’ve used my iPad in portrait mode approximately 0% of the time. It’s just awkward to hold that iPad in portrait, because of its elongated geometry. Positioning the sensor array at the “top” of that orientation makes no sense from a design standpoint, as it optimizes for an edge case, rather than what I’m guessing is “normal” use for most people. (Again, assuming that engineering challenges don’t make this a moot argument.)

On the other hand, if the sensor array were on one of the long edges of the device, Face ID would work just fine in either orientation for most people, as your hands would never be covering the array regardless of how you hold it.

Just a thought. I’m sure I’ll be proven wrong tomorrow. But I couldn’t let this thought go without at least documenting it.

When I came up with the original concept of RECaf, shortcuts hadn’t been announced yet. I knew the key to any data-logging app is making the act of adding new entries as simple as possible, so I focused all my efforts on reducing log friction. If it takes too much work, you won't get into the habit of logging daily.

I put a ton of effort into designing the simplest logging process possible. RECaf only needs three pieces of information to make a log entry: a source, an amount, and a date. Since most of the time you want to log an item you are consuming right now, RECaf can usually assume the date is now. If you tend to have the same sources in the same amounts regularly (we are creatures of habit, after all) RECaf can notice those combinations and make them more readily available.

Surfacing your top three most frequent sources automatically and making them one-tap buttons, then, became an easy addition. Adding a favorites pane for any extra items you sometimes log helps to capture most everything else. Even custom logging infrequent, non-favorite items I managed to get down to just a few taps on a single screen. Choose a category, source, amount, adjust the date if necessary, and you’re good to go. No scrolling through long lists just to find what you want.

3D Touch shortcuts on the home screen icon, the today widget, and a watch app give you those most frequent items in even more places.

But then Apple announced shortcuts this June, and things got way more exciting. People could just invoke Siri and say “Log Cappuccino.” And that was it. I knew I had to get this into my app immediately.

Using shortcuts with RECaf all summer has been a game changer for me. It’s supplanted most of the need to ever have to log the “old fashioned way.” Shortcuts have finally given me a reason to actually do something with Siri beyond setting a timer or adding reminders. I’m going to be looking to set up shortcuts in as many apps as possible this fall.

But there is one issue with shortcuts—they need to be set up by the customer in order to work. And in order for that to happen, the customer needs to know shortcuts exist in the first place.

And so we run into our old nemesis: discoverability. This is going to be the central challenge for designers working to add shortcuts to apps. Doing this poorly will cost you dearly. Your customers will overlook one of the best features to come to iOS in years. And that would be a real shame.

Counting on Apple alone to make people shortcut-aware would be a mistake. Remember iMessage apps? How many of those caught on with your non-tech friends?

Counting on Siri Suggestions would also be unwise. What are the chances your app will stand out in a suggestions list with 50 other apps competing for attention?

So how did I approach discoverability of shortcuts in RECaf?

Let me start by saying that I do not like to bombard my customers with tons of pop-ups and annoying messages trying to teach them about the app. Especially on first launch. We’ve all downloaded lots of apps at this point. The first launch sequence often becomes a battle of how many screens so I have to swipe or tap though to get to the darn app, already?

If you make the first launch more than a few screens, you’re lucky if the customer remembers anything you tried to teach them. If there are tons of permissions pop-ups involved, chances are they will tap through everything without reading.

I like to stick to what’s absolutely necessary on that first launch. For RECaf, that meant getting HealthKit access permission (because RECaf relies heavily on HealthKit) and (optionally) getting a free trial started. This way the customer can get the full experience of using the app right out of the gate with minimal interruption. You will need to decide what is most important for your particular app.

RECaf does not ask for notification permissions on first launch. (I save that for after your first log.) No prompting for ratings. (How can they rate an app they haven’t used yet? That comes after several days of use.) No tour of the entire interface. (They can do that on their own.) No signing up for any newsletters, etc.

I want my customers to get in and start logging.

So where do I add shortcut prompting?

Well, first I wanted to be sure that setting up shortcuts was easy, and that it could be discovered without any prompting. Not everyone will find shortcuts in RECaf on their own, but it should be possible at least, right?

After a couple of iterations, I ended up with buttons placed on every amount listed on the source detail page, with a microphone icon^[1], to indicate the customer would need to record a voice phrase. Maybe this person has never heard of shortcuts. Maybe they’re just curious and want to know what that button does. They tap the microphone, and Apple’s standard shortcut creation screen comes up and does the rest for me.

Once you’ve already recorded a shortcut for that amount, the phrase you recorded appears, and the icon is filled in. This makes it easy to see which amounts already have shortcuts, and it reminds you what you need to say to invoke that shortcut. Tap on the filled icon and you can edit or delete the shortcut. I show the phrases on the favorites screen as well.

So that takes care of making it possible to create a shortcut at any time for any source. But I’ll be lucky if more than a few people go hunting into the source detail screen on their own.

So how to balance making people aware of shortcuts without bombarding them?

I came up with a nice compromise. Here’s the scenario. You log a particular source/amount combination. (Say a 12 fl oz Café Cubano, as an example.) RECaf checks to see that all of the following are true:

• You have logged this exact combination of source and amount at least five times
• You have not already created a shortcut for this source/amount combo
• This combo is one of the first three where a shortcut was suggested, and then you created the shortcut.
• You haven’t yet indicated that you’d like to stop being reminded about shortcuts

If all are true, then after the confirmation screen indicating your log was successful, this screen will pop up:

From here, you can read about shortcuts and their usefulness, get a tip on how to create a shortcut for any source in the future, and of course tap a button to create the shortcut right there if you like. I also give you a way to either cancel just this particular shortcut’s creation (maybe you are in a place where you can’t talk right now), or inform RECaf that you’d prefer not to get these reminders in the future. That way, if you want to record the shortcut later, it will remind you again next time. But if you hate the whole idea of shortcuts, you can ignore them forever.

Note my thinking here:

• At least five times. I’m not going to push you into shortcuts on day one or for everything you log. It’ll likely be days before you see your first shortcut prompt. That’s okay. The app is still great without shortcuts. It’s just better with them.
• The app is making note of your behavior and predicting your future intentions. The simplest form of machine learning, to be sure. But machine learning all the same. (I’ll have more to say about the more complex machine learning surrounding reminder notifications in a later post.)
• The prompt happens in response to an action. It doesn’t just show up on launch, when you’re likely trying to quickly log something. It waits until you’ve done your logging and then prompts you with a helpful tip to make logging that exact item even faster next time.
• After you set up three of these shortcuts, RECaf stops. By then, you get the idea behind shortcuts, and you’ve been shown more than once how to set them up on your own. Maybe you didn’t read that screen carefully, but chances are, you’ll get curious enough to go looking elsewhere in the app at that point.

I know this isn’t perfect. If you always log from your watch, for instance, you’ll never get prompted. If you drink something different every day, it’ll be quite a while before any shortcuts get suggested. Some people will just cancel the screen every time without reading it or just tap the button and get confused. At the end of the day, it’s still a pop-up screen, which is an interruption and a potentially unpleasant surprise if you have no interest in Siri or voice-activated computing. But like I said, it’s a compromise. If RECaf bugs you once, you tell it to never bug you again, and it obeys, I’m okay with that.

The alternative is the majority of my customers missing out on what I think is the killer feature of the app.

I’m very curious to see how other designers and developers approach this problem. It’s challenging designing these solutions in a vacuum, before you get the benefit of seeing other approaches. Perhaps once I get a glimpse of some other apps with shortcuts, I’ll revisit and develop it further.

I’m also curious to see how shortcuts are adopted by my customers. With any luck, the majority will be logging with their voices a few times a day, then carrying on, only launching the app occasionally to see their stats.

RECaf will be available shortly on the App Store. To find out more, visit the web site or sign up on the mailing list.

While the toolset is inaccessible, its inclusion in watchOS 4.3.1 suggests Apple is at least considering opening that section of NanoTimeKit to outside app makers.

Whether a full-featured watch face customization toolset will ship to developers in a future version of watchOS, perhaps watchOS 5, remains unknown.

via AppleInsider

Man, I hope Apple doesn’t do this.

I know, it’s conventional wisdom that third-party watch faces would be the best thing since the Destiny’s Child reunion. But I think it would be a terrible mistake.

Designing a good watch face takes time and expertise. If you look at all the faces Apple shipped with the original watchOS, you can see they were all obviously painstakingly thought-out and implemented with care. Check out the custom animations in each one. The attention to detail. Even the faces I tend to never use are at least well-crafted. And there was a nice balance there between the more traditional and modern. More serious and playful.

It’s telling that of all the watch faces Apple has shipped since, only the Explorer is anywhere near the same quality of that original batch. All the others are either derivatives of the originals (e.g. Toy Story, Minnie Mouse, Timelapse), obvious examples of engineering over design (Siri, Activity), or complete WTF? (Kaleidoscope).

If Apple can’t even make good watch faces, what makes us think that random third-parties are going to do a good job?

Now that Jony Ive is back to paying attention to design at Apple again, what I’d like to see them do instead is contract out some experts in watch face design from the industry and have them work with the engineering team to add four or five really good new faces every year. Problem solved.

Flooding the market with crap, as we’ve seen in the App Store time and time again, would do more harm than good.

Do people really want the App Store to be overrun with “20 Awesome Watch Faces” apps?

Take a look at the Android Wear market, if you want a bird’s-eye view into exactly how hideous watch faces can get.

Sure, there may be the occasional winner. But I doubt it’ll be worth the effort of sifting through the garbage.

And given that there’s no way to charge directly for a watchOS app, there will be no financial incentive for anyone with skill to make faces, anyway. So then what? Watch faces with ads? Brand logos from Starbucks, MacDonald’s? It’s bad enough we’ve already got Nike logos.

So what, Joe? Just don’t use any of the third-party faces.

The watch face is the face of watchOS. Imagine Apple allowing third-parties to design macOS’s window style. (Yes, they allowed that many years ago, and it was a design crime of epic proportions.)

When Series 0 was introduced, people made fun of Apple’s attempt to make an elegant fashion timepiece. Apple has since retreated a bit into marketing Apple Watch primarily as an exercise device. I’d hate to see them cede the elegance altogether.

If Apple Watch is going to grow, it’s going to eventually have to get beyond the niche of exercise enthusiasts. That means it has to look good when you’re wearing something other than spandex.

Apple Watch needs to be respected.

I know when I’m wearing my stainless steel Series 3 I’m not wearing an Omega, Breitling, or Rolex. But I do want something that’s going to look nice with a button-down shirt or a suit. Turning the face of the watch into a third-party bottom-feeder billboard isn’t going to help.

Can you imagine Omega letting any Tom, Dick, and Harry design their watch faces?

I’m hoping against hope this was an idea tossed around for a few months, but now that Jony is back it’ll be emphatically squashed. It probably won’t be, but I’m going to keep hoping, anyway.

Mixology has been an interest of mine for many years. Not in the “let’s party all night until we fall over” way, but rather in an "appreciation for the finely crafted beverage after dinner” sort of way. I enjoy reading up on techniques, finding new recipes, and researching the histories of various cocktails throughout the ages.

Crafting fine cocktails and software design actually go hand in hand. They both involve a bit of art and science, and they both require an appreciation for getting things just right. Attention to detail is paramount. It’s no surprise so many in our profession enjoy amateur bartending at home.

For my next sticker pack, I wanted to celebrate my appreciation for mixology with a set of finely made cocktail drawings. From the various glassware shapes, to the joy of drawing lemon twists, this set of stickers was pure fun from start to finish for me.

I’ve represented several classic cocktails, like the Old Fashioned, the Manhattan, and of course the Gin Martini. (I’ve even done a Vesper Martini variant, as a nod to the Daniel Craig fans.) I’ve also added some of my other favorites, like the Sidecar, the Tipperary, and The Last Word. I hope to add more in the future.

There’s beer of course, if cocktails aren’t your thing. Pilsner, IPA, Stout, Belgian Ale, Hefeweizen, and a nice Irish Red. And if wine is more your thing, we have that as well.

Finally, I round out the set with some accessories familiar to anyone who has started a home cocktail operation.

If you like crafting cocktails, or you just want to send a quick invitation to go out with friends for a few drinks, this set will suit you well.

I hope you enjoy the stickers, and I welcome your feedback. Have a favorite cocktail you’d like to see included? Drop me a line.

You can learn more about all the sticker projects I’ve worked on here.

The Mixologist Sticker Pack is available now on the App Store.

The approach involved creating the icon twice: once as a textured 3D model, and again as a stack of Photoshop shape layers. This seemed nuts — doing twice the work for the same result. Yet there are benefits. The freedom to scale up an icon indefinitely without rerendering is among them. But, more importantly, the Russian “double-drawn” method affords a much higher degree of control.

(via John Marstall on Medium. Linked via The Loop)

This is very similar to the method I used on the Teleprompt+ 3 icon. I created a teleprompter in Cheetah 3D, lit it, rendered it out very large, then recreated the exact angles and shapes using vectors in Photoshop so that it could scale to any size. Then I could tweak the color and shading as needed.

Even with vectors for the final product, I needed to tweak every single icon size manually, of course.

It was all the way back at WWDC 2014 that my friend Hans vershooten suggested what eventually became the marquis feature of x2y 4.0: Percentages.

x2y has always been able to calculate x or y dimensions for you automatically. It would be nice, Hans suggested, if it could also tell you the percentage difference between the original image and the new one. So if you want, for instance, a rectangle that’s exactly 245% of the original, x2y should be able to calculate both the x and y dimensions for that.

And now it does. (Sorry it took so long, Hans.)

Other new features in this update include 3DTouch shortcuts on the home screen, for devices such as the iPhone 6s and 6s Plus. You can jump straight to a particular aspect ratio with one gesture. To customize which aspects end up in the shortcuts, simply put them at the top of your customizable common aspects list.

Also new in this update, two new color themes. I have fun changing up the look of x2y on occasion, so I wanted to add a few more options. Also, all themes are now unlocked by default, so no more hunting around looking for ways to get all the themes to unlock.

I’m a bit surprised that years after this app was first released, I still find myself using x2y several times a week. This was my first app, and I never imagined that I could take it so far. Once again, I can say with confidence that I’ve spent more time thinking about aspect ratio calculators than anyone else on iOS.

x2y an invaluable tool for any designer or developer who needs to resize images often, particularly in code. You can download it on the App Store here.

Seeing this tweet a lot today in my timeline.

Here's another way of looking at it. Original iPhone screen in the empty space between the apps on the iPad Pro. pic.twitter.com/MwVLiwp8cL

— Dennis Munsie (@dmunsie) November 11, 2015

The comparison is wrongheaded, because the people sharing it are confusing points with pixels.

The original iPhone screen did indeed have 320 horizontal pixels. It was also a 1x screen, which means it had 320 points, as well.

The iPad Pro’s screen, on the other hand, is a 2X Retina screen. Thus, the 324 pixels between the app columns on the home screen represent 162pts, or roughly half the width of the original iPhone’s screen. Even that isn’t quite accurate, because the two screens also have different pixel densities. But the point is, the comparison makes no sense.

I am typing this on an iPad Pro, and I assure you, an original iPhone’s screen wouldn’t come close to fitting in between the home screen columns of the Pro.

More importantly, the point those who are sharing this are trying to make is also flawed. More space on the home screen does not mean we should jam pack it with more icons. Just because you have the space, that doesn’t mean you should fill it with more options. This is UX design 101.

I don’t know what the maximum number of icons on a screen is before the number of options becomes too confusing to the average user, but I’m willing to bet Apple does. I’m also willing to bet there’s value to having a little bit more consistency between the layouts of the various home screens of our iOS devices. Imagine setting up your new iPad Pro from a backup of your old iPad Air. Having all your apps not only restore, but restore to their familiar layout goes a long way to making that first run experience more familiar and pleasant.

“But the home screen just looks ridiculous with all that space between the icons.” This is an unbelievebly dumb reason to add another column or row of icons as well.

There’s no doubt in my mind Apple tested the Pro home screen with more densely packed icons and decided it was a bad idea. They obviously have the technical expertise to have the Springboard space icons in various ways, because they’ve done it with the various screen sizes of the iPhone. Perhaps in this case, the extra icons didn’t add value. Perhaps they have research from their customers that users find it annoying having inconsistent layouts. Who knows? The assumption that Apple is simply being lazy, or that average Twitter guy knows better is astounding, though.

How could he hope to reinvigorate a workforce stunned and disoriented by the loss of their mercurial, touchy, moody but magnetic leader? The one man band had lost its one man.

But since Jobs’s death Apple’s fortunes have not gone into decline. In fact the growth graph has climbed ever more steeply. The figures are simply incredible.

(via The Telegraph)

Now, why would Stephen Fry start this article reminding us that Jobs leaving Apple wasn’t the end, that in fact the transition to Tim Cook turned out well for Apple?

Just as the February New Yorker article served to introduce us to Richard Howarth, and the Wired piece in April introduced us to Alan Dye[1], all three of these pieces have served as a preparation for the eventual retirement of Jony Ive from Apple. This is one, long, calculated PR move. And it’s being executed flawlessly.

And that shouldn’t surprise us. This is simply what a top-level executive leaving the world’s largest corporation looks like. A person such as Jony Ive can’t just retire from Apple one day. He or she must transition, over the course of a year or more, so as to cushion the impact on the stock price, public perception, etc.

Start by making it look like a “promotion.” Then spend the next several months talking up the accomplishments of his replacements. (I wouldn’t be surprised if we started seeing Howarth and Dye featured in upcoming design videos and/or appearing on stage at Apple keynotes.)

By the time Jony actually leaves Apple (in a year or two, most likely), we’ll all be relatively comfortable with the idea of Richard Howarth and Alan Dye running the design of the company. Just as the vigilant among us knew that Tim Cook was going to handle things just fine once Jobs was gone.

Will some part of that old Apple magic be gone without Jony? Of course. But this is inevitable. Sooner or later, the theory that a company’s culture can outlive its leaders needs to be tested. And tested. And tested yet again.[2]

Meanwhile Jony will spend the rest of his time at Apple extracting himself further and further from the products and diving into the bigger challenges of retail, work environment, and so on. His legacy. His long-term impact. Can you blame him? If you were Jony Ive, would you really want to spend the next six months working on yet another even thinner iPad?

1. Credit goes to Ben Thompson for the Howarth/Dye insight, from this morning’s member’s-only daily update. If you’re not a member, you should consider it.  ↩
2. If Apple is still humming along when none of the executive team members from the Jobs era are still around, then we’ll know that the company can truly endure. I suspect it will be.  ↩

My official talk from Mobile Conference Europe 2015 is now available online. My topic was “Design as if No One is Watching.” A bit of a call to remember who we work for as designers building great products on teams.

It was incredible to take part in this conference back in February. Highly recommended, if they do it again next year, that you consider attending. Special thanks to Jarek and the whole team over there for making it a wonderful experience.

I’ve been looking closely at iOS 7, and like many designers I have mixed feelings. Some of the changes, like the expanded use of motion, are a breath of fresh air. Animation is coming to the forefront and will only be further explored in the years to come. And that’s very exciting. In other areas, meanwhile, such as the heavy reliance on type rather than icons, the over-reliance on plain white backgrounds everywhere, and the lack of clear separation between elements such as the status bar and the title bar, I’m a little less convinced. (And I won’t participate in the icon debate, except to say that there’s more work to be done, I hope.) But I understand that this is a rough draft, that all Apple interface design is a work in progress, and that the “big shifts” (just like the original OS X) usually take a few iterations before Apple works out where they may have taken it too far in a particular direction.

And that’s where my work moving forward comes in. Unlike Apple, I only have a handful of apps to conform to this new iOS 7 design language, so I can take some extra time with them. And the number one guiding principle for me is this: Don’t overcorrect.

I think a lot of designers will be tempted to strip out all adornment in their apps and try too hard to copy the stock Apple apps. This would be a mistake.

Take my app x2y, as an example. I started thinking about what I would need to do to make this fit in with iOS 7 immediately following last Monday’s keynote. And what I’ve concluded is that it does need some work. But not as much as I initially thought.

Sure, I can further flatten out the already pretty flat toolbars, remove the highlights and shadows from my custom number pad, maybe back off on some of the background texture. And I can get rid of some of the custom adornments that don’t really need to be there, such as the logo on the top of the interface. But should I switch from the dark grey to a more iOS 7-common white background? I don’t think so. When I use this app, I’m usually in my dark office, with my focus on my iMac’s 27” screen. The last thing I want is my iPhone or iPad blasting white light at me just so I can make some image size calculations.

And what about the font? Helvetica Neue Light is nice, and I actually like the system-wide movement toward thinner fonts on Retina screens. On the other hand, Futura is a major part of x2y’s personality. Those sharp, beautifully recognizable numbers were chosen for a reason, and I can’t see replacing them just because the system font has changed. I can, however, in the interest of improving clarity, make those fonts larger in some places.

After a few days of playing around, what I ended up with is something along the lines of this. A change, to be sure, but not a drastic one. A look that won’t be out of place on iOS 7, but would still work on iOS 6 as well.[1]

One of the nice things about iOS as opposed to OS X is that once your app is launched, it takes over the entire screen. So while you want it to fit in with other apps on the system, there is plenty of room for your own app’s personality to shine. You can have a custom look and feel, so long as the user experience is consistent and it doesn’t look too out of touch.

My advice to my fellow designers is to not take the new look of iOS 7 too literally. Remember the core of what Apple’s trying to achieve—clarity, deference, depth—and interpret those principles in your own fashion. Sure, hard light from 90-degrees above is giving way to more diffuse, ambient lighting, and heavy drop shadows and distracting textures are likewise passé. But don’t try to make all your apps look like iOS 7 Mail. That would be counterproductive.

After all, Letterpress looked and worked just fine on iOS 6. Twitterrific fits in nicely on either system. Because good design is good design. It’s much better to be in the position of potentially influencing Apple’s next version of iOS (as those two apps clearly did) than to be copying the current version.

1. Note, this is three days worth of work on the next version of x2y. The final product may vary quite a bit as it gets refined over the next few months.  ↩

“So, will Jony Ive remove all textures and ‘designs that look and work like real things’ from iOS? I highly doubt it. There’s simply no reason to make unilateral design decisions like that outside of frustrating designers and making things worse for users.”

(via The Next Web.)

Extremely well thought out argument from Matthew Panzarino here. I agree with it completely.

People love to take the extreme sides of every argument. X is always right. Y is always wrong. But as we all learned when we prepped for multiple choice tests in high school, so little in life is always or never true.

My guess is Jony Ive is currently looking through every app on iOS and assessing what works and what doesn’t. He’ll make changes where he feels change is necessary. No more. No less.

Besides, do we really want every app on our phones to look and behave exactly the same? One of my biggest issues with the Windows 8 flat style is that it pins designers into a corner. You lose the ability to make your app really shine on the platform once you rule out too many possibilities. Sure, it looks nice with five or six apps, especially since it’s such a change from the iOS look. But what about when you have fifty apps? Or a hundred?

I was really happy that I was able to learn enough Objective-C to make my own app, put it on the App Store, and see other people getting use out of it. The response has been great so far, and I’m planning lots of new improvements already.

But I’d be lying if I didn’t admit there was one thing, visually, about the app that was bugging me. And that was the default Apple keypad.

Not that I don’t think Apple’s keypad is a great design. It looks good and it functions perfectly. But because I had chosen to use Futura throughout the app, the default keypad’s use of Helvetica just didn’t quite blend with the rest of the app’s look. It’s the kind of thing maybe most people wouldn’t notice, but my audience here is graphic designers. So this was important, no matter how much I tried to convince myself otherwise.

I also didn’t like the color of the keypad for my app, nor the use of letters under the keys. The letters make sense for phone dialing, but they were adding visual clutter that is completely unnecessary for my purposes.

Because I was a noobie to programming, I assumed that changing the default keyboard would be a huge pain in the butt. So when releasing 1.0 I decided to live with it.

After all, you have to make compromises to ship apps, right?

Then I started playing around with making the app iPad compatible, and I quickly realized that the iPad doesn’t have a default keypad. You literally have to roll your own keypad if you don’t want to use a full keyboard.

So I figured I have to build my own keypad soon, anyway. Why not put it in the iPhone version first?

As with many other aspects of iOS app creation, coming late to the party made my life a lot easier. Switching out input views in iOS is a lot easier now than it was when iOS was much younger. That’s not to say it wasn’t still more work than it should be, however.

While dropping in my new, pretty, Futura keypad, I got to see firsthand what so many of my developer friends have told me over the years. Every time you solve a problem in your app, two or three new problems seem to crop up. I pop in new code, and something breaks somewhere else. You think you’ve got one new thing to learn how to do, but you actually end up having to learn how to do four or five other things before you’re done.

It was a huge reminder of just how little I really know, having just built one simple app. But it was also encouraging, because ultimately I was able to figure it out on my own. One more thing I’m confident I can do the next time it comes up. And several other things I understand about how classes and nibs work that I didn’t know.

A look at the before and after, I think, speaks for itself. This is a huge improvement to the app.

Version 1.1 was submitted last night, and will be available as soon as Apple approves. I also added in a few extra ratios to the list of Common Aspects whlie I was at it.

Now to tackle the rest of that iPad layout.

I work with an amazing team at Bombing Brain Interactive. While my role there has always been visual and user experience design, along with web site development, one of my goals this year was to branch out a little into real, honest-to-goodness app coding. Not that we don’t already have an abundance of coding talent going on with Gene and Tim, but because I wanted to improve my skill set and make myself more valuable to the group in any way I could.

I believe firmly that in order to work with other people in various disciplines, it always helps to learn a bit about what your collaborators do all day. Not only does that help inform decisions you make in your own role, it also helps with empathy for your teammates. You need to appreciate everyone else’s contributions, and that’s so much easier when you can see clearly just how hard their jobs are.

Does that mean I plan on being a super-pro coder someday? Not necessarily. But I did want to bring something more to the group than I was able to a year ago.

So I embarked on a quest to learn Objective-C and to get more comfortable inside Xcode.

I didn’t come into this with no coding experience at all. I do have several years of Javascript, HTML, CSS, and a touch of PHP under my belt. But I don’t kid myself into thinking any of that makes me a programmer. That’s baby stuff, essentially. And I’ve never had any formal training in C or any other computer language. I’ve always sort of hunted and pecked my way into figuring out whatever the current project needed, much the same way I did with Photoshop and Illustrator so many years ago.

So I picked up some books, downloaded some course materials from Harvard’s excellent CS50 on iTunes U, and started reading and learning in my spare time.

Then I came across Mysterious Trousers’ TinkerLearn series. And for whatever reason, that style of teaching really worked well for me. How TinkerLearn works is you download full Xcode projects, and all the lessons are embedded in the files of a real working app. This way, you get to experiment and learn about real code in a very practical way, in context.

After a few lessons, I decided to give myself a project. I’d take an idea and turn it into a full-fledged working app that I could develop all the way to the App Store. I needed something small and easy enough to do without getting overwhelmed, but at the same time, I wanted it to be a challenge, and I wanted the app to be something I’d actually use.

So after some thinking I settled on an Aspect Ratio Calculator. Three main reasons why this was the perfect project for me to work on as my first App:

1. It wasn’t your typical tip calculator, or other sort of “my first app” project. It was different enough to not be an also-ran, without being something that was completely useless to anyone, either.
2. I’m a web designer, and I really need to do these sorts of calculations often. So it was a personal project. Usually the best apps are ones made by people who want to use those apps every day.
3. The aspect calculator apps that were already on the Store weren’t lighting my world on fire. No offense to the other fine apps in this category, but most of them haven’t been updated in quite a while, don’t offer much in terms of visual design, and don’t tackle the problem the way I feel I would want it done. In other words, I needed this app, but nothing on the Store was fulfilling that need to my personal satisfaction.

And thus x2y was born. Simple. Elegant. Solves a real world problem. Whenever I wanted to add a feature that I didn’t know how to add, I would consult YouTube, Apple’s Documentation, web articles, whatever I could get my hands on. It’s amazing how much knowledge is out there, free or very cheap, that could get anyone up to speed on making apps. Developers are extremely generous with their knowledge.

At one point, I even enlisted Tim to help me out with a big problem I was having. As expected, he suffered my noobie questions with grace and got me back on track.

When I started this project, I thought maybe I’d get it done by sometime next year. But once I got past the first few big bumps, I became more driven to finish it. And then I remembered all the other stuff that goes into launching an app. The web site, the screenshots, the description, the keywords, the user guide—there was plenty to keep me busy, but the closer I got, the faster I worked.

I’ll be happy to sell ten copies of x2y; my goal here isn’t to have a big hit. After all, this is a niche app, and a very simple one at that. But I am proud to see that I was able to get all this done in a few short months and that I sweated the details as much as I did. Forcing myself to put the app out there on the Store, with my name attached to it, ensured that I would take every aspect of development seriously. This may be the first app of someone new to Objective-C, but it was built with all the design and user experience expertise that I’ve built up over several years making iOS apps with others.

I’m looking forward to my next project, which will challenge me even further.

But mostly, I’m just glad I’ll finally have a good aspect ratio calculator on my iPhone whenever I need it.

x2y is available now on the App Store for a special introductory price of just 99 cents USD. More infomation can be found on the official x2y web site.

Today I’m launching my first iOS app, x2y. While I’ve collaborated on many apps with my partners at Bombing Brain Interactive, this is the first app developed entirely by yours truly and published under my own name.

x2y solves an old and common problem. You have an image or other media file, and you need to display it at a different size than the original. But when resizing the image, you need to be careful to keep the aspect ratio consistent, so that your media doesn’t get stretched or pulled.

So you take the original dimensions, the height or width of the desired new dimensions, and cross multiply to get the new missing dimension.

x2y helps make that calculation much simpler. Nothing more or less. Clean. Elegant. And best of all: Futura.

The app is fully compatible with both 3.5-inch and 4-inch Retina screens, works well with Voice Over for the visually impaired, and includes a full user guide within the app itself.

I’m really proud of the way x2y turned out. I had a simple goal this year of learning enough Objective-C to make myself more valuable to the Bombing Brain team, and I thought the best way to do that would be to give myself a project and see it all the way through to the App Store. And because I was putting my name on it, I wanted it to reflect every bit of the polish and care that would go into any project to which I commit myself.

I hope you enjoy x2y. You can find out more at x2yapp.com, or buy it today on the App Store. The special introductory price of 99 cents USD is for a limited time only, as a thank you to my friends and readers. If you have any feedback or want to see a feature added, there’s a contact form on the x2y web site.