The other day I posted about how the design of lists (or UITableViews) could be improved with only a few changes. Today we’re going to look at designing a main menu screen for an iPhone app. (We’ll get around to talking about designing for iPad in a bit.)

An easy default main menu is using the standard UITableView. Return to the other post to see an example of what a bare table view looks like. Pretty bland.

Stop thinking about lists & tables

A main menu should only have a few options. The key to improving the design is breaking free of the concept that it has to be a list using UITableViews. Sure, each menu option may lead to a UITableView but you don’t need to start the navigational drilldown from a list. What else could you use? Buttons. And this might be where you’re going to need the aid of a graphic designer. Programmers: proceed with caution; you could go crazy bad with the design if you’re not careful.

With a few minutes in Interface Builder you can whip up a menu with buttons. Here’s an example:

Functional but not very attractive. It uses standard iPhone interface elements but it can be a whole lot better, especially as the first screen you see.

Think about what kind of buttons: shape, size, color, etc. Where will they be positioned on the screen?

With the 4 day app I thought about the overall concept behind the app. One of the striking aspects of some barrios in Buenos Aires are the cobblestone streets.

Since this is an app about getting around Buenos Aires I wanted to see if I could incorporate cobblestones as part of the design. At first I thought the buttons could be in the shape of cobblestones. “Cool,” I thought for a moment. Then I remembered a solid piece of design advice I learned from Ceci: discard your first idea. It’s usually cliche. Instead, take the underlying concept and view it from another perspective. Then keep thinking about it, which probably lead to a much better idea. (Eventually I learned that process is true in so many creative endeavors: acting, writing, painting, etc.)

Back to cobblestones, the streets of Buenos Aires, and the app. Figuring out what to do in 4 days in a foreign city is about making choices. On our shelves is the novel Hopscotch by the beloved Argentine writer Julio Cortázar. The original Spanish-language covers is very well-known.

That led me to wonder if the menu could be represented as a child’s sketch of a hopscotch game on a cobblestone street. I went to Ceci with the idea. She came up with a graphic that we finally used as the main menu.

Buttons in iOS can be transparent. Simply overlay a transparent UIButton on top of each of the areas of the graphic that you want to be touch points. For effect we also added a little to glow to each button as it’s tapped since it’s helpful to give people visual feedback on a touch screen interface.

Oh, that little “i in a cirlce” graphic (the info button) down in the lower right corner: that’s just the standard built-in button as “info” circle into iOS. It’s great for seldom used menu options like about this app.

With a dose of creativity and design you can easily enhance the aesthetics of your app.

On the iPhone a fundamental UI component is the list, which is known in iOS programmer-speak as a UITableView. The default appearance is rather plain but does have the coolness associated with all Apple interface elements. Yet, because it is so common that also makes somewhat boring and doesn’t bring anything special to your app. Your apps don’t have to be plain. Apps can look nice and well designed, but it might take the eye of a graphic designer to help a programmer get there.

Let’s examine one app we developed and the evolution in designing its list format. Here’s an example of the final result so that you have an idea as to where we’re heading with the design.

This app received a 5-star rating in the app store. Of course, as with all design, the best app designs are not apparent. Notice how the design is never mentioned in this review:

This app does the nearly impossible: suggest (successfully, I should add) a four-day itinerary for Buenos Aires. As anyone who has been there knows, the city is huge. Having been there twice, this guide is as spot on as it can possibly be. Be warned, no city is as easy to negotiate as a mobile phone app — there will be dozens of distractions, travel delays, and discoveries as you go. I wouldn’t want anyone to just stare at the app all day! However, this is a great app for helping cut through all the overwhelming information about BsAs — good, clear suggestions you can trust completely.

There’s so much more to developing and designing an app than visuals. Indeed, it’s very easy to get sidetracked in designing an app by trying out all sorts of variations. An essential part of managing the app development process is knowing when to stop experimenting and just get the app completed.

The day screen

Since this app provides a 4 day itinerary to Buenos Aires, the heart of the app is a set of 4 screens: one for each day. We’ll use day 2 (shown above) as our example in exploring how this design evolved.

The example uses a UIViewController with a UITableView rather than a UITableViewController.

Barebone

In its most basic level our tableview looks very plain. In fact, Apple even refers to this type of table as plain.

In iOS-speak plain actually refers to the fact that the table is one list without any sections. The other type of table is a group table and is divided into sections. You see this on many apps. For the 4 day app it wasn’t necessary to divide the listing into sections, so I started out with a plain table. (Another post will take a closer look at designing a group table.)

Give it some color

A background image is easily added and makes a lot of difference. A golden paper-like textured background was created as a jpeg at a size of 320×416.

To associate the background image in the code I created a property called “imageView” and made the connections in Interface Builder. (I’m leaving out a few steps, obviously. So if you’re new to iOS development then I recommend a book for you: Head First iPhone and iPad Development: A Learner’s Guide to Creating Objective-C Applications for the iPhone and iPad is a particularly gentle introduction, plus it has a fantastic book design.)

self.imageView.image = [UIImage imageNamed:@"background.jpg"];

Be sure to first set the background color of the tableview to clear in order for the background image to display. And you’ll also need to make the cell transparent by setting the background color of the cell to clear.

cell.backgroundColor = [UIColor clearColor];

Work the text

A number of excellent font choices are built into iOS, plus you can embed your own fonts. If you don’t know anything about fonts then stick with Helvetica. For this app we tried something a bit different and chose to put the main entry in Georgia-Bold.

And we deviated from the standard black and added a color that complements the background image.

cell.textLabel.font = [UIFont fontWithName:@"Georgia-Bold" size:16.0];
cell.textLabel.textColor = [UIColor colorWithRed:0.427 green:0.38 blue:0.314 alpha:1.0];

Specifying colors in iOS

If you’re a Web designer or work with any desktop tool, then you probably noticed something different about the way the color is specified in the above code. In iOS you don’t identify colors with hex or rgb numbers. Instead, you use a UIColor. The easiest way to figure out these values is just to plug in the results from an online UIColor converter.

Add a subtitle

Remember the early 1990s and Gopher? Don’t let your tableviews look like something from 1993. And don’t make users select an entry just to see what it’s about. Unlike Gopher, in iOS menus you can add a second line (a subtitle known as a detailTextLabel) to each entry.

cell.detailTextLabel.text = [[listOfItems objectAtIndex:indexPath.row]objectForKey:SECONDLINE_KEY];

Since detailTextLabel is a separate property from textLabel it doesn’t pick up the same formatting. That’s good. In the above code you can see how I’m pulling the text from an NSArray named listOfItems. Another part of the code not shown here actually parses a property list, which is a type of XML file for storing small amounts of data.

Here’s the screen with the detaiTextLabel added.

Give it some space

The screen looks very crowded. Not good. Let’s give some breathing room to the cells by just changing the row height in viewDidLoad:

self.tableView.rowHeight = 80;

Play around with that setting and see what works best.

I chose 80 for the row height because I want to add another visual element to each cell.

Images have meaning

Cells can have an image on the left side. Images are not just decorative but convey meaning about that menu entry. Since the available space for an image in a table cell is so small I recommend not to use thumbnails. So often when I suggest using a small image in a cell people jump to the conclusion that it’s a thumbnail: a miniature of a larger image. The response is usually, “The thumbnail will be so small that no one will know what it is.” That’s true and it’s why you don’t want to use thumbnails.

Instead, create a small image that is a detail from a larger image. Details are wonderful ways to enhance a project. Let the detail serve as a representative of the whole image.

I created a set of detail images 50 x 50 to go in each of the cells. (Note that you’ll also want to create a 100×100 detail image for use no Retina Display devices.)

As an example here’s a large image:

Here’s the detail used in the cell:

See the difference between a detail and a thumbnail miniature of the entire image? The detail works so much better.

Add the code to enable the detail image to display:

UIImage *cellLeftImage;
NSDictionary *dict	= [listOfItems objectAtIndex:indexPath.row];
NSString *fileprefix = [dict objectForKey:BACKGROUND_KEY];
cellLeftImage = [UIImage imageNamed:[NSString stringWithFormat:@"%@.png", fileprefix]];
((UIImageView *)cell.imageView).image = cellLeftImage;

Hmmm, looking good but look closely at those images. It needs something around that image. Add a border. Remember to import QuartzCore/QuartzCore.h in your header to get the border properties working properly.

[((UIImageView *)cell.imageView).layer setBorderColor:[[UIColor grayColor] CGColor]];
[((UIImageView *)cell.imageView).layer setBorderWidth: 2.0];

Careful use of images on the left-side of a cell can make a huge difference in improving the design.

Don’t forget to change the selected highlight color

You’ve gone to all this trouble to add a nice golden palette to your screen, so you want to be sure and change the color used to highlight the menu when touched. If not, you’ll get the default blue:

Yikes. Continue in the method where you customize the tableview cells

- (UITableViewCell *)tableView:(UITableView *)tablesView cellForRowAtIndexPath:(NSIndexPath *)indexPath

Add the code:

UIView *goldenColor = [[[UIView alloc] init] autorelease];
goldenColor.backgroundColor = [UIColor colorWithRed:0.824 green:0.749    blue:0.553 alpha:0.70];
cell.selectedBackgroundView = goldenColor;

And the final result:

That’s it. Remember this isn’t a step-by-step tutorial but assumes you have a working knowledge of Objective-C and the iOS SDK. That’s not the hard part. The trick is figuring out the design.

Developing native apps for Apple’s iOS devices (currently: iPod Touch, iPhone, iPad) is certainly a complex process. Of course, that’s true for almost anything worthwhile. Fortunately, app developers are usually the type accustomed to learning new tools & skills. Back when I managed technology in universities, I hired programmers based on not what they knew but on their aptitude and skills for learning. And I still think that’s valid for hiring developers on salary to work in-house, but I suspect most publishers will contract their app development to firms specializing in those skills.

While there is a significant learning curve for new app developers, Apple provides an extensively documented environment for building apps. The learning curve is about three months to obtain a firm understanding of developing apps in Objective C and Apple’s SDK (known as Xcode). Clearly, though, the learning of new techniques and more involved aspects of the iOS SDK is an ongoing and never ending process. Again, that’s also true for any development environment.

Some sort of programming background is essential for coming to terms with the tools for iOS app development. Experience in a C-based language is helpful but not necessary, though having a basic understanding of how a programming language functions is essential. Those with only a background in scripting languages such as PHP or JavaScript will have a slightly harder time but not so much harder. Personally, I actually find Objective C a lot simpler to understand that JavaScript but that might simply be the way my own mind is wired.

Developing a native app requires a very different mindset than developing for the Web. The screen dimensions is only one aspect. Apple provides great guidance in its interface guidelines. And there are many technical issues. You must deal with memory management. Xcode provides both an iPhone & iPad simulator but what works on the simulator may not work on the actual device, which has much stricter memory limitations than a desktop machine. The complexity of loading views (i.e., a screen of information) is not nearly as simple as making an href link to a new Web page. In iOS a lot more is going on behind the scenes. Of course, that also opens up a great deal of functionality, features, and capabilities that can be presented in a native app.

Knowing how to take advantage of those features in native apps requires an understanding of the possibilities presented by iOS. And that’s where the design of the app is so very important, and not just the visual, graphic design but the underlying structure and functionality of the app. The value of an app rests in the functionality, which really needs to be something more than a page curl animation. That’s merely eye candy. The task of conceptualizing an app is the most difficult part of working in Apple’s app world. But that’s nothing new. System analysis and design always has been more difficult than programming.