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.

Despite my absolute love for the iPad, I’m certain that Amazon’s new Kindle Fire
will be a successful product for consuming content. Let’s not debate that; the market will tell us within a few months.

How do we design and develop for Kindle Fire? There are seven questions I’m wondering about.

1. What type of tools will Amazon provide to developers?

Sure, Kindle Fire is based on Android but uses an earlier, forked version customized by Amazon. If Amazon wants to offer a large variety of apps on Fire then it needs to offer guidance on how to best develop for the device. For instance, Apple provides a clearly written Mobile Human Interface Guidelines document. Whereas, on the announcement day of the Kindle Fire, Amazon’s developer site says to come back next week to learn how to develop for Fire.

(Hmmm, perhaps secrets are hard to keep within Amazon and they didn’t want the technical writers to know too much before the product announcement.)

As with Apple, developers will have to pay Amazon a $99 annual fee to sell on the Amazon Appstore. It’s waived for the moment, so now is a good time to sign up. Presumably, the developer’s fee goes to cover the cost of creating the SDK and documentation. That’s fine, but Amazon can never beat Apple in the quality of tools and documentation. (Actually, Amazon doesn’t have to beat Apple at anything. Plenty of room in the market for both Kindle Fire and iPad to co-exist.)

2. Will the positioning of Kindle Fire as a consumer-grade device for content determine the type of apps created?

If so, then the range of apps will be fairly limited, which is not necessarily a bad thing. The two-point touch screen of Kindle Fire will restrict it as a gaming platform. Fire does not need to be a productivity platform since many who have Fire also will have a smartphone on which they can use productivity apps. Obviously Amazon will provide its own apps for watching movies and reading e-books. So that really leaves content apps in the form of books, children’s books, cooking, entertainment, lifestyle, reference, and travel. Most apps in those categories are relatiely similar beneath-the-hood and don’t necessarily make use of the most advanced parts of an SDK. So, watch to see what types of documentation and sample code Amazon provides.

3. For designing e-books will Kindle Fire ever support EPUB?

In one sense Amazon never needs to support EPUB since a third-party app for Fire could support EPUB instead, though it’s hard to imagine Amazon encouraging an iBooks or Nook app for Fire. But maybe so. In the end, consumers don’t really care about EPUB or format standards at all. Consumers care about the price of ebooks and the reading experience, so it’s likely that the overwhelming majority of book lovers who buy a Fire simply will stick with the Kindle app. This leads to the next question…

4. If not EPUB, then how close will Amazon go in supporting layout capabilities similar to those in EPUB3?

Seems like e-book designers are following the same trail as Web designers in having to tweak layouts depending upon the consumer’s choice of application. (With Kindle playing the role of IE in this saga. Let’s all sigh a bit.) But if Amazon keeps the capabilities of rendering e-books fairly close to EPUB then it’s not that big of a hurdle to support multiple e-book formats. Or, perhaps, Amazon could even take the lead and implement advanced capabilities before EPUB3 is completed. That won’t be good for e-book standards but could further strengthen Kindle’s position among consumers as the best e-book reading device.

5. How will the limit of 8 GB of storage force changes in the way apps and e-books are developed for Kindle Fire?

On the iPad many content-based apps are very hefty, often weighing more than 500 MB and occasionally more than 1 GB. On my 16 GB iPad I have to be very careful about managing those last two gigabytes. I had to delete both Al Gore’s Our Choice app and Tim Flannery’s Here on Earth app to ensure my iPad maintained space for new materials. (BTW, those are both good apps. The Our Choice has a small initial size but downloads a lot once you start reading each chapter.)

The 8 GB Kindle Fire may require re-thinking how many apps and e-books are structured…leading us to the next question.

6. Will the cloud-based caching technology in the new Silk browser also be utilized to support apps and enhanced e-books?

I’m hoping Amazon has some intelligent way to cache the enhanced content of an e-book and deliver it from the cloud as needed, and then remove it from the device cache when no longer needed. If so, the same could be adapted for apps that embed massive amounts of video and images. I’m very curious about how Amazon will handle this characteristic of many apps and e-books. I’m suspecting that the intelligent caching will be built into the entire system and not just the Silk browsing.

7. Will Kindle Fire quicken the adoption of Web apps?

Amazon could sidestep the entire dilemma over supporting developers in creating native apps by instead encouraging the development of Web apps. Indications are that the Silk browser is based on Webkit. As the Web app stack of HTML5, CSS3, and Javascript matures then it becomes a better option for cross-platform development. Even though HTML5 isn’t quite baked, the modest functional requirements of content-based apps might make it a viable option sooner than later.

Apple probably is not nervous about Kindle Fire, though every other tablet maker should be quite worried. Amazon is the only one with a retail ecosystem to match iTunes. And that’s what it’s all about.

Kindle Fire cannot be ignored by designers and developers of content-based apps and e-books. Time to figure out the strategy for supporting both iPad and Kindle Fire.

The world of iPhone & iPad is dangerously seductive. It’s easy to get drawn into a months-long development process to build an app filled with swipes, taps, and an array of gestures for controlling the interface. Resist that urge. Resist trying out all sorts of variations in the interface. (Explore those in prototyping tools, not in real test versions of the app.) Keep it simple. Users appreciate that.

And simple gets your app to market faster. The reality is that most apps sell very few copies unless you have a solid marketing campaign in place. As with any form of publishing there are few blockbusters in the world of apps. If you’re aiming for a successful app, have funding for four to six months of development, along with six months of marketing. Start marketing while the app is still in development.

A mentality of build it and they will come is naive. With that atitude your app will sell only a few copies on its first day of release. The app store gold rush is long over. Further, there’s no longer a bump in sales for new apps appearing in the new releases of the app store. Apple proudly cites hundreds of millions of users with credit card numbers on file with iTunes. But people are not going to find you through the app store alone. Your own marketing has to bring them.

For the last year a side venture of mine has revolved around the creation of travel guides for iPhone (and its sibling the iPod Touch). As with many startups, most of our early efforts were consumed with organizing, planning, and prototyping. In August we finally launched Endless Mile.

Our first title is the specialized guidebook Recoleta Cemetery in app and e-book formats. Endless Mile guides do not aim to encompass everything that a tourist needs to know about a city. We’re not setting out to compete with Lonely Planet, Rough Guide, Time Out, Frommer’s, Rick Steves, or any of the other major guidebook publishers. Our guides, selling for a just a few dollars each, are intended to supplement those standard resources (as well as non-traditional tools such as TripAdvisor. We don’t provide lists of hotels, restaurants, or even an exhaustive listing of sights to see. We leave that to others.

Instead, we offer destinations in context. Our guides appeal to curious travelers who want to understand why a particular building is historic or why a spot is considered a landmark. Our digital guidebooks serve as a companion for your journey, as well as a way to remember your visit and share the memory with others.

Why not just Wikipedia?

A significant number of travel apps derive their content from Wikipedia. And the blogosphere is filled with reviews praising the wonders of wondering around a city looking at whatever you like and learning about that spot from Wikipedia. We certainly encourage wandering even though our apps provide a more curated experience of a city. (My business partner in Endless Mile is a long-time tour guide for Rick Steves, so there’s a strongly guided focus to what we offer.) I use Wikipedia all the time to get a gloss on a subject but the sterile writing style forced upon entries in Wikipedia leaves me yearning for a more engaging read. For travel destinations that’s where Endless Mile fills the gap between encyclopedia article and a full-length book on the topic. And, in some cases, such as with our own app on Recoleta Cemetery: there is no other in-depth coverage in any language, in any format, than what we provide.

Perspectives of a developer turned publisher

In a series of posts I’ll be sharing my experience with developing apps and e-books. Topics to be covered include soft launching a first app, utilizing the same content for app and ebooks, establishing a publisher as a developer on the iTunes app store, building an engine as a template for producing multiple apps, offline vs online mapping, app marketing and the web, designing a five-star app, and more.