I’m a programmer who occasionally dabbles in user interface design when I’m doing solo projects. I know enough to know when a UI is bad or good, but I’m at a loss on how to create good UI from scratch. On my iPhone games, I do my own UI. There’s the iPhone Human Interface Guide, but I feel that it’s a bit hard to digest and I feel that it’s too specific to non-gaming applications.

Tapworthy takes iPhone HIG then mixes it with insights from recent user interface research and human psychology. The result is a very readable guide with specific do’s and don’ts to follow in designing your iPhone app interface. The tips, along with the long but readable discussion on the principles behind those tips, are general enough that even game developers will find them useful.

For example, the recommended hit region for user interface elements should be 44×44 pixels. This is a very important principle to follow (n00b mistake: on an app I was developing, I started with swipeable coins that are 20×20. Not surprisingly, on my first user tests, the users found the coins too small and very hard to swipe). The iPhone HIG actually mentions this, but this tip is buried in there and is only mentioned three times. In Tapworthy, this tip has its own section title (“The Magic Number is 44″) and is mentioned more than a dozen times to really drill in the point.

Another solid tip from the book: Do not use text in designing the app’s icon. It won’t be readable, and it will just add visual clutter to the icon. This tip is actually part of an entire 30-page chapter (Chapter 7) devoted to App Icon Design.

I can’t find anything that I don’t like about this book. It can use some improvements, though:

• Given that roughly half of iPhone apps are games, it could add more tips specific to gaming applications. Maybe games aren’t in the author’s repertoire, and that’s a topic for another book.
• The book contains lots of internal references, e.g. “…a concept explained in the Facebook case study on page 236…”. On the PDF version, the references aren’t links, though. What’s more, on the ePub version, when reading it on Stanza for the iPhone, the links are meaningless because the ePub pages on Stanza doesn’t really match the PDF’s page numbers. This isn’t major, though, and it’s something O’Reilly can easily fix with an updated digital release.

If I have to describe this book in a nutshell, I’ll say it’s Alan Cooper’s About Face, translated to the iPhone world. Great work.

I think Corona is a great kit for writing games in general, especially arcade games and board games. There’s no built-in support yet for tiled maps, and it looks like Cocos2D will have that built-in first. But even with that disadvantage, developing on Lua is so much more productive than developing on Objective-C that I’ll still come out ahead.

Some apps aren’t a good fit, though:

• those that extensively use the CocoaTouch UI controls. In Corona, you have to create your own buttons, text fields, etc. There’s the ui library, but it only covers a few controls.
• those that access APIs that aren’t wrapped yet by Corona. For example, access to the address book seems to be missing.

There’s the worry that Corona SDK will violate section 3.3.1. Folks from Corona gave some reassuring messages, but of course, with Apple, you can’t have absolute uncertainty. My take is that even if Apple gives Corona the boot, Corona will become Android-only, and Corona SDK is worth $99 even as an Android

I’m taking the $99 plunge. If nothing else, I think Lua will give me a refreshing break from my day-to-day Ruby and Javascript coding.

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

It’s been about a month since 3.3.1 came out. The most obvious impact of this is on Adobe Flash CS5. Prior to 3.3.1, Adobe has announced that Flash CS5 will include a Flash-to-iPhone compiler. Now, Adobe has cancelled that feature.

Here’s a roundup of how the other iPhone development tool providers have reacted to 3.3.1. Except for funkaster, writer of shinycocos, most of them seem to be optimistic that they’re in the clear.

AnscaMobile (Corona SDK):
http://blog.anscamobile.com/2010/04/corona-and-iphone-os-4-0/

Torque (iTorque):
http://www.torquepowered.com/community/blogs/view/19715

Unity:
http://blogs.unity3d.com/2010/04/10/unity-and-the-iphone-os-4-0/

funkaster (shinycocos):
http://github.com/funkaster/shinycocos/commit/9ebda7fcfc853db266b4b49c01bdbc5fa5a9be42#comments
(see the comments below the git commit)

Rhomobile:
http://rhomobile.com/2010/04/09/iphone-4-0-sdk-rules/

Me? I’ll stick to learning plain XCode, Objective-C, plus the Cocos2d Library.

Attendees:
topher
rad
eumir
buddy
tin
nico

There were two new attendees, tin and nico, who promised to catch up with the previous assignments.

We discussed memory management. The following questions were raised:

When should you call release on an object?

When you’re the one who did the alloc for the object.

When should you not call release?

When you did not do the alloc for the object.

Why bother with alloc and init at all, when, for example, you can use class methods that do it for you?
For example, why use:

NSString *my_string = [[NSString alloc] initWithFormat:@"format"];


when you can instead the format below?

NSString *my_string = [NSString stringWithFormat:@"format"];


Answer: The stringWithFormat call returns an autoreleased object. On the Mac OS X desktop, there’re practically no difference. On the iPhone, you want to limit the number of objects in the autorelease pool and use alloc/init most of the time so that you can be explicit (and optimize) on when you call release.

As before, let’s try to do Week 3 in one week. That means lectures 5 (Views, Animation, OpenGL) and 6 (View Controllers), and assignment 3 (HelloPoly II). Let’s aim to view the lectures and finish the assignment by next week and have a meetup Thursday next week, February 25.

For those that are catching up and still working on previous assignments, feel free to post questions about them, both on the forum and on meetups.

It starts on Feb.15. Even if you don’t know anything about Objective-C and Cocoa, you still have some time to cram. You can actually get by with what you’ll learn from the first three chapters of this book: Beginning iPhone Development: Exploring the iPhone SDK.

See you in the class!

Er, the class is virtual, so see you in the class forum instead.

Attendees:
paul
topher
rad
johann
eumir
buddy (cakey)

We skipped discussion of assginment 1A as it was really very simple and no one had problems with it.

Assignment 1B has four sections, so we took turns in discussing our solutions. Paul discussed section 1, Topher section 2, Rad section 3 and Eumir section 4.

Topher mentioned some confusion in creating the project under XCode 3.2/Snow Leopard. The screenshot provided by the handout was for XCode 3.1/Leopard. If you’re on XCode 3.2/SL, see the screenshot below on how the New Project dialog should look like.

Everyone was excited and wanted to try a bit faster pace. Tentatively, the next meetup is on Thursday, February 11. It will cover Lectures 3-4 and assignments 2A and 2B. We’ll check our progress over the weekend, and if this pace doesn’t seem workable, people should cry chicken as early as Monday, February 8.

Lastly, the off-topic discussions were also productive. Here are the links to the tools mentioned in passing during last night’s meetup:

Topher’s framework of choice for building iPhone apps:
http://github.com/blog/389-three20-iphone-ui-goodness

Rad’s framework of choice for building iPhone games:
http://www.cocos2d-iphone.org/

Rad’s framework of choice for Flash games:
http://flixel.org/

Interesting paper prototyping tools:
http://apress.com/book/view/9781430228233
http://www.appsketchbook.com/

1. The study group will move at half the pace of the CS193P class. This means two lectures and 1-2 assignments every two weeks. There will be one meetup every week.

Week 1 starts on January 25, 2010. Everyone views the lectures and works on the assignments on her own. There will be a meetup on February 4 to discuss concepts and assignment solutions.

The mechanics are still being ironed out, but here’s what I’m envisioning:

1. The study group will move at the same pace as the CS193P class. This means two one-hour lectures a week, and one assignment a week.
2. Each participant will view the lecture videos on her own
3. Each participant will work on the assignments on her own
4. There will be an optional once-a-week meet-up to work on assignments together. Everyone still work on the assignment solution individually – the assignments have been designed that way – but the meet-up is an opportunity to have a high-bandwidth discussion on difficult concepts.
5. There will be once-a-week meet-ups to “submit” assignments and discuss solutions.

The meet-ups will from 8pm to 9pm and will be held in the Ortigas office of Sagada Solutions.

If you’re interested in joining the group, please join this Google group.

A new class has just started, and the material has been updated for iPhone OS 3.0. Videos of the lectures are available for free in iTunesU one week after the actual class.

Watching the videos (of the 2009 class) and working on the assignments has been the best iPhone programming exercise I’ve done so far. Highly recommended.

Follow the class here: http://www.stanford.edu/class/cs193p/cgi-bin/drupal/

Recently I decided to join the Get Rich By Selling an iPhone Game bandwagon. I had several things going against me. First, I’m starting from scratch when it comes to Objective-C and Cocoa. Second, this is completely unrelated to my current work, so I will not be able to port any know-how I gain from work into this new endeavor. Lastly, I still have to maintain my full-time job, and my family obligations, so this will at best get 5-10 hours a week of attention.

After several months of pursuing this inconsistently, my efforts have paid off and I finally am at point where my confidence in building an iPhone game is at about the same level as my confidence in building a web site on Ruby on Rails (my full-time job). I haven’t released a game yet, but I think I’m finally over the steep part of the learning curve.

If you’re planning to embark on a similar journey, here’s some advice:

1. Enroll on an iPhone programming course

I didn’t, but if one was available locally when I was learning, I would have seriously considered it. What I discovered during my learning process was that spending just one to two hours per session (the most I can spare in a day, given my full-time job and family obligations) for learning a completely new language and framework was very unproductive. I got stuck on most of those sessions, then I spent a considerable portion of the next session retracing my steps and figuring out where I stopped during the previous session. I made the most progress when I took a leave for several days from the my full-time job to concentrate on my studies.

Here are the bootcamps I recommend:

• Big Nerd Ranch
• Mobile Orchard

Alternatively, you can follow the Stanford CS193P iPhone Application Development class. Video transcripts of the lectures are freely available in iTunesU. The assignments are great, IMHO even better than the iPhone books. I’ve been looking for the Objective-C equivalent of the K&R book, and the lectures and the assignments come closest to it.

2. Go through these books, in order

• Introduction to Cocoa Application Tutorial
• Cocoa Fundamentals Guide
• Beginning iPhone 3 Development, 2nd Edition
• The Objective-C Programming Language
• Coding Guidelines for Cocoa
• iPhone Human Interface Guidelines
• iPhone Developer’s CookBook: Building Applications with the iPhone 3.0 SDK 2nd Edition

If you follow the Stanford CS193P class, you will find these books very useful. The Apple reference docs are your, well, references. The Beginning iPhone book and the Developer’s Cookbook will be helpful if you find some concepts aren’t adequately explained in the lectures or in the reference materials.

3. Get an actual iPhone or at least an iPod Touch

Theoretically it’s possible to build and release an app by just using the simulator, but it’s not recommended. Here’s why:

• You cannot test multi-touch and the accelerometer using the simulator
• You need to be an actual iPhone OS user to be able to understand the UI expectations of your users. You need to actually use an iPhone or an iPod to be able to appreciate much of what’s written in iPhone Human Interface Guidelines
• Apps, especially games, will be much slower on an actual device than on the simulator. You need to verify that your app won’t be sluggish on an actual device

4. Start with a framework

I recommend the cocos2d-iphone framework and the chipmunk physics engine. Both are free and are supported by a healthy community. They may not be the best, but they’re accessible and are enough to get you started.

5. Lastly, always remember to have fun!

That’s what this is all about, right?