iPhone X and Why I’m (sort of) Ignoring the HIG

iPhone X and Why I’m (sort of) Ignoring the HIG

What Apple Wants

The iPhone X has been out now for several weeks, and slowly but surely, I’m seeing app compatibility updates hitting the store. According to Apple and the HIG, the message is a loud and clear, “embrace the notch!” But will designers and developers follow those instructions? Immediately after the initial announcement, there were plenty of ideas (and jokes) about how to deal with that pesky notch. I’ve been a bit slow on getting my metronome app Click ready for the iPhone X. I ended up making some design choices that I thought might make for an interesting blog post, sort of striking a middle ground between the letter of the “law” in the HIG and going completely wild by totally hiding or calling attention to the notch. These decisions were also influenced by the existing style and purpose of the app, so I’ll talk briefly about those factors as well. So, without further ado, let’s dive in!

Here are the most important official summary statements from Apple about handling the “key display features”:

Avoid explicitly placing interactive controls at the very bottom of the screen and in corners. People use swipe gestures at the bottom edge of the display to access the Home screen and app switcher, and these gestures may cancel custom gestures you implement in this area. The far corners of the screen can be difficult areas for people to reach comfortably.

Don’t mask or call special attention to key display features. Don’t attempt to hide the device’s rounded corners, sensor housing, or indicator for accessing the Home screen by placing black bars at the top and bottom of the screen. Don’t use visual adornments like brackets, bezels, shapes, or instructional text to call special attention to these areas, either.

My Design

So, will people follow the rules? How flexible will app review be with apps that push the boundaries? It certainly appears that many people do not like the notch, as evidenced by such sites as notchless.space for creating notch-hiding backgrounds! And, what did I decide to do with my design? I’ll include the current preview video of Click from before iPhone X, as a little intro to the design of the app as it already was. A few things probably jump out to you right away as potentially interesting on iPhone X: the completely black background, and the presence of a LOT of elements laid out way into the corners of the display.


Hiding the Notch?

Continue reading “iPhone X and Why I’m (sort of) Ignoring the HIG”


Updating for Modern iOS Design – A Case Study

TL;DR — Check out the pictures and videos on this page, and you’ll see how I adapted the basic circular menu of Click version 1 to fit the new iOS 7 design aesthetic, not just in visual terms, but also in interaction style: clean and almost chrome free, with more color, more seamless transitions, new inertial/physics-y interactions and direct manipulation transitions.


Hello Again!

As you can probably imagine, a LOT has happened in my life in the last almost two years since I’ve posted on this blog (and therefore also on iDevBlogADay)! And most of it has not been iOS development related, so I guess that’s my excuse for such an incredibly long time between posts. But, I have been working when I have the time, and I just released a new version of my iPhone app called Click Metronome. The original version was the topic of many of my posts here on this blog, especially about the design of the circular control. For this post, I thought it might be interesting to explore some of the design changes I made to Click when releasing version 2. The principles behind the design – and the features of the app – are largely the same, but the actual look and feel is completely different. So first, how about a look at a screenshot from version 1, and then the promo video for the new version for iOS 7+. Can you guess which is which? 🙂


Screenshot 2014.08.02 13.38.42


Circular Menu

At the time, I was really happy with how Click turned out. Then – and now – there’s a lot of metronome apps out there, but they seem to either be too simple and missing key features, or feature-rich but with a screen that’s completely full of buttons. So, one of my main goals for Click was to offer all the main features people would want – wide tempo range, variety of time signatures, accent options, etc. – and make them quickly accessible, but without cluttering up the screen with tons and tons of buttons. So, after much iteration, I came up with this menu system that showed all the current settings around a small circle. Then, the user taps an item and all the options for that setting are revealed in the circle, ready to be set by rotating. Here’s that menu in action in version 1 and version 2 (watch in slo-mo):





Version 1 Problems and Fixes:

I felt like I accomplished the goals I had set out, and watching people as they used the app, they always eventually figured out how to use it. But, it was never as intuitive and easy as I had hoped. As I got feedback from others, and as I thought more and more about the app myself, I came up with a whole list of problems with the implementation of the menu:

Continue reading “Updating for Modern iOS Design – A Case Study”

Click – A Postmortem

The App

My latest app, an iPhone metronome called Click, has been out for two months now, so I thought this would be a good time to do a little postmortem reflection on the development process, the launch, and some thoughts for the future. I’ve discussed some of the development and design of the app before on my blog, but I haven’t yet done much discussion of how it all turned out. So, here goes…if you’re mostly just interested in the numbers, then skip to the end (although I’ll give you a hint: they’re not too large).

What Went Well

1. The Design

There are still some things I want to tweak, but overall I’m very pleased with how the general look and feel of the app came out. It was incredibly satisfying to go through the whole process of brainstorming ideas, testing them out, and then finally settling on a design and control scheme and actually seeing it come to life. It was definitely a learning process, and even though it was slow going, I can look back on my time spent with this project and know that it wasn’t wasted time. I was focused on creating a certain “look” for this specific app, but everything I learned about Core Graphics, UIKit, and Photoshop is instantly transferable and applicable to future projects. There were certainly times that I wanted to give up on the customization, throw in a few stock UIButtons and ScrollViews and just ship this stupid thing, but in the end I’m glad I stuck it out! Being able to turn your vision of what something could be into a real, working product is, for me, one of the greatest joys of software development.

2. The Features/Scope

I spent quite a lot of time and effort thinking through exactly which options and features I wanted to include in this app. The only real required feature of a metronome is that it produce sound at a regular interval (and yes, probably also with some type of visual feedback), and the only required option is to be able to set the tempo to the desired speed. This is all that a traditional hardware metronome does. But modern metronomes – of the software and the hardware variety – have so much more audio flexibility: time signatures, variable accent patterns, subdivide the beat in various rhythms, multiple sounds, storing setups for creating set lists or practice routines, programming longer sequences for specific songs, and on and on. There’s also many varieties of visual feedback available, especially in the realm of software metronomes. I made the decision that one of the key distinguishing features of Click would be the ability to select Continue reading “Click – A Postmortem”

Some Good News and Some Bad News

I’m sure everyone is busy playing with the new bits from Apple right now, or lusting over the new hardware just announced, so I’m not sure who all will see this, but it’s my slot today for iDevBlogADay, and I’ve got some news to share, so I’m going for it!

I’m so mad at myself right now. The good news is, my new metronome app “Click” was just approved and is Ready for Sale!! The bad news is, I used a promo code to download it before releasing it for sale, and… it’s got a bug. A big ol’ freaking whopper of a bug. Somehow as I finalized my image assets, one of the resources had the wrong name in the Nib file – there was an “@2x” left on the end of the image name in the Nib configuration for the UIImageView. The app runs and loads fine in the simulator, and I swear the final build worked fine on my device too, but apparently the App Store release build is more picky and couldn’t locate the resource. So, one of the key pieces of the interface is invisible. So guess what? I’ll be waiting another week at least for another review. I could possibly ask for an expedited review, seeing as this is a “critical bug,” but the problem is the app isn’t actually even for sale yet, so it’s not like the bug is actually “live.” I don’t really wanna push my luck and/or annoy the review team now and then really need an expedited review later. So, one lesson is, keep testing the crap out of your app even after you submit, and you just might catch something and be able to developer reject your binary before the review starts. The other, real moral of the story is: delay the release of your app at least enough to generate a promo code and try out the released version for yourself. I have no idea when promo codes started working for apps before they’re actually released, but it certainly saved me this time! My thanks to @wtrebella for bringing this to my attention when he was tweeting about releasing Polymer.

I must say though, this isn’t all bad. I’ve been working on this app for over a year. I’ve been wanting to integrate a quality metronome into another app of my, theDrumDictionary, and in future music-related apps. So, this was supposed to be a quick side project in learning Core Audio and how to make a metronome, and since I was going to do it anyway, I figured, why not release a standalone metronome app too? But I didn’t want to make just another metronome app, and as I explored how to differentiate mine from the existing options, it sort of exploded into this very large project with difficult to implement (for me) custom controls and a large amount of Photoshop time designing a unique UI. Needless to say, I’m ready to get this thing out there and see what happens! When it comes to an initial release, I actually came to appreciate the sort of built in waiting period of the app store review time. Being forced to stop coding, it was a great chance for me to finalize my press materials and continue to get the word out about the new app. I was expecting to be done a *lot* sooner than how it turned out, and by the time I submitted the app for review, I knew I was going to be running right up against WWDC. Who’s going to care about some no-name company’s metronome app in the middle of big hardware and software announcements?! If approved during dub-dub, how long should I wait to release the app? Or should I release the app, and just wait until later to do press releases, etc.? Or is it really most beneficial to do a launch all at once – app appearing on new releases, press release, etc? (Great articles from Justine Pratt on marketing, by the way!) Well, now I don’t have much choice! I’ve probably got another whole week to keep up the marketing prep, spread the word to existing DrumDictionary customers, etc., and there’s not much worry about WWDC anymore. I’ve got to release this sometime, and a whole week after the big keynote seems like as good a time as any to me; it’s certainly much better than anytime this week. And, I can confidently run a full on launch blitz with no fear that I’m messing it up by separating the app release from the press release OR driving myself crazy as I wait for days for the right marketing timing knowing that it’s just sitting there ready waiting for me to change the availability date. I suppose I shouldn’t be too mad about it after all! (but let’s face it, I’m pretty pissed). Anyway, maybe this gives you something to think about before you release your next app! And, if you’re curious, head on over to my new Gig Bag Apps website and check out the trailer for Click. Maybe it’ll be a hit; if I ever actually release it 🙂

Introducing: Click

I’ve mentioned my upcoming metronome app a few times before on the blog here, but now that I’m getting closer to completion, I thought I’d take a moment and give it a formal introduction. It’s still very much a work in progress, so don’t take this as a press release or a marketing video. It’s more like, a behind the scenes intro from a developers perspective. So, without further ado, here we go!

The Name

“Click,” or perhaps with a subtitle, “Click – Metronome” is the title of my new app. Honestly, I’m not 100% happy with this name. To the general population, it’s probably pretty ambiguous, hence the subtitle. But among musicians – who would be the majority of those purchasing this app – a “click” is a common way of referring to a metronome. Basically, there’s a lot of metronome apps out there, and this was one of the only non-corny, non-“punny”, simple, to-the-point names that was not yet taken.

The Design

It’s easier to show you this than to try to explain it – so jump to the video if you want – but I want to share some of my rationale/process of design for this app. There’s lots of metronomes out there (are you seeing a theme yet?), but from a design perspective, most of them are just plain crap. Now, I’m no design expert by any means – it’s only been in the process of making this app that I’ve begun to truly dig in and study principles of UI and UX design. So, that being said, if even I can see  – and articulate why – these apps are crap, then they must actually crap!! Seriously though, there are some good metronomes out there, but there’s definitely room for more quality ones.

One of the issues I see, even with the good ones, is that they want to be powerful and give the user a lot of options, but in doing so they sacrifice usability. Even the easy to use ones still end up filling the entire screen with buttons and cram the visual part of the metronome itself into a small section of the screen. So first and foremost, I wanted to find a way to give plenty of options, but still leave lots of screen space for the metronome itself. In that respect, I’m very pleased with how the circular menu/selector has worked out for this.

As far as the actual *look* of the design goes, I’m shooting for something with both realism AND digital “flexibility.” It’s realistic in the sense that the app looks like a real object – with shadows, highlights, texture, some physical buttons and handles, etc. But, it’s not overly skeuomorphic and doesn’t necessarily directly resemble any real-life metronome. The main controls and the central view are basically just “screens” upon which I can display anything I want, completely unrestrained by what would or would not work on a physical device.

Another thing I wanted to do with this app is minimize the use of words or labels. Obviously, there are a lot of numbers used – no way around that really when you’re talking about setting specific tempos and time signatures – but there’s very few words. As long as I can find appropriate symbols to communicate what each thing does, I think this will give the app a nice, clean, accessible quality. Not to mention how much easier localization will be when there’s only a handful of words in the whole app!

The Video

Enough talk, just watch! Not everything is working yet, and even the working things are still in progress, but this will hopefully give a nice preview of what’s coming up. I’d love to hear any feedback you’ve got, positive or negative! Thanks for watching.

—-  Yikes! The video quality did not turn out too well after compression. Oh well, you get the idea. It looks *great* on the device, I promise  🙂  —-

P.S. – Wanna Help Test?

If you’re interested in helping beta test Click, follow the link here to Test Flight. I may not be able to take everybody – Apple’s 100 device limit is turning out to be more restrictive than I realized at first – but I will take whoever I can. If you’re a musician or otherwise particularly “qualified” to test this app, that will help me narrow it down if I need to, but it’s not a requirement. Thanks!

Test Flight – http://bit.ly/zjcd0g