I’m working on my own home-grown podcast playing app for the iPhone as a way of learning Objective-C, the Cocoa frameworks, UIKit, etc. It’s been months of reading and toying with code in my spare time, but I have a little bare bones app that I use every day now to suit my needs. It’s a long way off from being released to the general public, but it’s always exciting when I can check off the next feature I want to add or trick I want to pull. That’s the joy of programming.
It’s been rumored for a long time that Apple was going to come out with its own podcast playing app, and that finally happened this week. Podcasts are leaving iTunes and moving to this app. Podcasts can be subscribed to from the app and downloaded straight to it. (Stay away from doing that in 3G land, though. That data hit could get ugly.)
I mention all of this now because the Apple Podcast app has the main menu that I wanted to implement in my app. And rather than being dismayed that they beat me to it, it’s been a big confidence boost to know that I was thinking along the same lines as Apple.
Here’s a scrap of paper I originally outlined my idea with:
What you see to the left is my drawing of the screen. It’s a series of icons, shown two across, for as many tiers as necessary. It’s labelled “Podcast Choice” at the top. Here’s what I wrote along the right side:
“Large Targets”: This is important to me. There are far too many apps that use such small controls that I accidentally hit the wrong control. Podcast apps are the worst for that. The Apple HIG specifies something like a 44 pixel square tap zone, but I think there are a lot of developers who don’t go much larger than that. Bad.
“Important: No icon get cut off on screen 1”: This is in direct opposition to what I wrote later in the notes. Let’s skip to that one:
“How to indicate more choices below? Show tops of next row of icons?” This is the right way to go. If there are six icons perfectly centered on the first screen, the user doesn’t have a visual clue to continue scrolling in any direction to see more. You need to cut off the last row of icons so the user knows to scroll down for more. It’s more intuitive that way.
Here’s what the Apple podcast main menu looks like:
Notice the last row there? Yup, it leads you to scroll down. And Apple is doing the same pair of icons all the way down technique that I was thinking about. It’s nothing new. The Windows Metro interface is built on it, and that influenced me. So did Marco Arment’s Instapaper app, which has a menu for choosing articles that looks like this, too. And I know we’re going to see a lot more of it in the future now that Apple is using it.
Again, I’m just happy that some of the details I was sweating were some of the same details Apple was thinking about. I’m not claiming to be a revolutionary here or anything. It’s just a nice feeling to have.
“White space between?” My drawing had gutters between all the icons. So does Apple’s.
“Name on tile (color)?” Apple does not have a podcast name on the title. It is solely up to the app to have their name on the tile. And, more often than not in the cases you see on my screen, the podcast producers have their network name along the bottom. I had thought of doing some kind of semi-transparent overlay over the bottom quarter of the tile with the podcast name on it. Still might.
“If odd # tiles, leave last spot plain white? Or put something in?” Apple goes for a blank spot, which I think I likely would have done, too. You can’t put a feature button down there because then you’d lose the feature every time you have an even number of podcasts. You could drop an ad in there, I guess, if you were so persuaded. I have no ad model planning for my app.
“How to indicate button press? Grey out on Tap Down? Change border color?” I still don’t know about this, but Apple doesn’t indicate anything. You tap, and the app switches to the next page.
I haven’t done much with the main menu screen at all, yet. I have a much more basic implementation right now, and I think that whenever I do release this thing into the wild, I’ll stick closer to that than a completely graphical tile-based navigation. But that will only be due to my own slowness as a learning programmer, rather than any strongly-held belief about app design.
More to come in the future. . .