Last month I took a vacation to visit my parents in Hawaii. It's a grueling 5-6 hour plane trip, so I made sure to load up on some of interesting iPhone games before I left. Though I wouldn't say that the flight raced past, they did help to assuage my boredom. They also got me thinking about the user interfaces in their designs.
About User Interfaces
We did talk about user interface in iPhone in Action, but we only paid much attention to it on the web side of things. And, there was a good reason for that. When you're working on the web you don't have pre-built classes available for your use which match the iPhone look-and-feel, so you have to think about how to use existing tools to duplicate the style of the SDK. (Fortunately, there's some great answers on how to do so, thanks to tools like Dashcode and iUI, both of which get attention in our book.)We didn't pay much attention to user interface when discussing the SDK, and again I think that was for a good reason. We mainly talk about how to use the various tools that Apple provides you with, and if you're using those tools (particularly the various UIControl classes and other buttons, switches, and doodads) you're innately going to be using the iPhone UI.
Games, however (like those that I took with me to Hawaii), are built on a somewhat different paradigm. They're more likely to display graphics that fill the screen, which means that your UI will not depend on existing SDK classes. Instead, you're going to be depending on your own creativity to design original UIs.
However I strongly believe that any user interface you build should adapt the iPhone UI standards as much as possible. (And see iPhone in Action pages 81-84 for what those standards are: we wrote it for discussion of the web, but it's equally applicable to original graphic UI designs.)
There's two reasons to do this:
- Your users will already be familiar with how to manipulate your program.
- You'll be using an interface that's already tried and tested and is thus one of the better ways to accept input from users.
That brings me back to those iPhone games that I brought with me to Hawaii. The two that I played most each had small (but annoying) problems with their UI. I wanted to show them to you here, to highlight the sorts of problems that you can create when you go off and design your own interfaces and to talk about how to correct them. In the process, I'll show off each of these two reasons for adopting iPhone standard interfaces.
iHearts
I'm going start off with the simpler program, a version of the classic Hearts card game called "iHearts". It's by DMBC and it's an OK game. The rules seem to be adapted correctly and the graphics are simple but attractive. On the downside, the AI is pretty beatable.
The user interface, however, has a real annoyance. As pictured at right, whenever you want to select a card to play or trade you do so by clicking on the card and then when the golden double-arrow appears, clicking that to confirm.
I'll wait a second while you try and guess my complaint here.
The problem is that this select-and-confirm interface isn't used very often on the iPhone. You see it in some places, like when you choose to delete a cell from a table, but it's not standardized, and especially not for an action like a card play.
However, there is an standardized action for this sort of play, and I'd guarantee that it's what 75% of users try to do when they first play this game: touch-and-drag. The obvious action is to touch the card you want, then drag it out to the middle of the playing space. It can even give you a confirm by "ghosting" the card that you want to select and returning it to your hand if you don't pull it far enough out onto the table.
I can see two reasons that the programmers of iHearts might have chosen their click-and-confirm method rather than touch-and-drag. First, it is slightly easier to program, especially if you're not familiar with the iPhone. Second, if you were programming a desktop game, I think there's about a 50% chance you'd do things this way.
However, the iPhone is a unique platform, as we underline in iPhone in Action, and thus I think it's always worth considering what the iPhone standard UI is and if your program would be better off if you used it.
Lock 'n Roll
The game that I spent most of my airplane time playing is "Lock 'n Roll" by Canned Bananas. Though I'm going to talk critically about a small element of its user interface, let me say first that Lock 'n Roll is a great game. You roll dice and arrange them on a 4x4 grid, trying to match colors, numbers, and/or sequences in order to score points and clear spaces. It's a good game design and the core UI of the game is fine. In fact, it does what I said iHearts should have: you select dice by touching, then dragging them from the roll gutter to the grid.My UI problem has to do with the subsidiary pages available from the "info" button on the main page. Here's an example of the sequence of pages leading to the high score page:
Again, I'll wait a moment while you try and figure out how this UI might have gone slightly wrong.
In this UI you click "info" to go to the middle page which lists a number of options, then you click a bar to go to a sub page, such as the high scores page. My problem with all of this is the totally superfluous middle page.
The SDK has a standard way to create these sorts of sub pages: the tab bar controller. Lock 'n Roll could easily have had a tab bar across the bottom of the main game page, listing their six options ("Play","Scores", "Rules", "Credits", "Web Site", and "Options" ... though it'd probably be better to put the Credits and Web Site together). Doing so not only would have created a standard interface but also it would have saved users one click every time they did anything.
And that goes back to my second reason for using the iPhone's standard UIs. To put it most succinctly the iPhone UI programmers knew what they were doing. I'm not surprised at all that using a standard iPhone interface (the tab bar) leads to a real advantage (one less click), because that's what I'd expect to see when using a polished interface design.
One last point: the Lock 'n Roll designers might not have wanted to use a tab bar thinking that it wouldn't look as attractive as the rest of their stylized graphical interface. They might be right. However, if you come to that conclusion for your own designs, consider how you could create a functionally similar interface that still meets the graphical needs of your program. Would a hand-drawn tab bar across the bottom of the main game screen have melded the Lock 'n Roll graphics with the iPhone user interface? I suspect the answer is yes.
Conclusion
Don't think that either of the UI interface issues that I point out is a game breaker. Both iHearts and Lock 'n Roll remain on my iPhone. At this point, I think that Lock 'n Roll gets the most use of any iPhone app I have, other than Safari.
Despite the fact that the UI issues in both programs are minor, I still think they serve as excellent examples in the discussion of user interface design: how you can vary from the iPhone standards and how you perhaps ... shouldn't.
Comments