Tag Archives: design

My Talk at MCE 2015

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.

Course Correction

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]

x2y in its current form on the Left. Proposed redesign for iOS 7on the right.

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.  ↩

The Skeuomorph Debate

“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?

It Bothered Me Enough

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.

X2y newkeypad


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.

Why Would a Designer Want to Learn Objective-C?

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.