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.

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.

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.

My first job as a teenager was in a library shelving books. During college I spent more time in the library than anywhere. My favorite shopping experience always has been in a bookstore. Browsing rows of titles gives me a certain euphoria. Somewhat astonishingly, I get that same feeling when browsing online booksellers.

A short time after college I found myself in library school, which—in fact—had very little to do with books but all to do with information. The container didn’t matter. Within a relatively brief span I went from totally ignorant of computing to fully conversant with the emerging networked world of the early 1990s. Mastering the Unix command-line, perl scripts, and developing websites in vi propelled me towards digital libraries.

Libraries, though, frustrated me. Don’t get me wrong. Libraries are wonderful places to work. But the core of libraries—organizing, digitizing, storing, and retrieving information—left me yearning for more involvement with the actual content. I hungered for how people used the content rather than how they used the metadata. The topic of digital narratives took on a greater appeal. How could the story be told differently through digital media? That’s far outside the scope of librarianship, so after fifteen years I stepped away from the profession.

A romance with an Argentinean led me to Buenos Aires and book design, which formed the genesis of SoroDesign. In the first years our studio dealt primarily with the design of print books. Despite that, a curiosity remained about the shifting nature of narrative in the digital space. Like many, I was skeptical of e-books initially but now I’ve come to embrace e-books. (Please, though, let’s all work on improving the aesthetics of e-book layouts.)

And yet…and yet…there continues a steady question…a consuming passion about the transition from print to digital, especially forms of narratives that are alternatives to 80,000 words of text.

Enhanced e-books leave me lukewarm. Multimedia in the form of apps intrigues me, though I suspect enhanced e-books will morph into Web apps. I fear I talk too much in generalities. It’s time to get specific. That’s the next stage of my career as our world moves from book to tablet.

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.

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.

When an app serves our purpose most will accept its limitations. We’re seeing that most clearly with all the e-book reading apps. Some people hate iBooks simulated page turning with the faux borders of a print book. Others prefer the more basic approach of the Kindle app. For reading long-form narratives most of us who have embraced e-books tolerate the idiosyncrasies of the Kindle app or iBooks since accessibility and portability far outweigh any disconcerting aspects of reading on a screen.

And that’s the difference between print and digital, and largely now the difference between e-books as apps and as ePub: apps can offer much more than reading on a screen.

The highly acclaimed Our Choice, Push Pop Press’s production of Al Gore’s text, is a remarkable example of how book apps can engage readers in learning about climate change, even offering an animated primer on how electricity is generated for those of us who never quite grasped the origin of electrical currents, underscoring the capability of an animation to convey more meaning than a static image. The static image needs more elaboration whereas the animated image is instantly graspable.

John Gruber properly analyzes the differences between e-books as known via Kindle/iBooks apps and the type of e-book offered up for example by Push Pop Press:

Kindle and iBooks seem to have the goal of reproducing what is possible in paper books. Yes, iBooks supports embedded video and audio content, but it does so in a way that feels as though Apple pondered what it would be like if you could play video on a piece of paper. Push Pop’s concept strikes me as far more ambitious: What can we do with the idea of a “book” if we eliminate the limitations of ink and paper, rather than mimic them? E-books that aren’t merely rendered by software, but rather e-books that are software.

It’s easy to see why textbooks will transition to this format and why companies are working to develop educational apps. Textbooks are not at all about reading long-form prose but about absorbing modular content that is carefully constructed to facilitate learning.

While JavaScript-enabled interactivity will emerge for ePub-based e-books and, surely eventually, also for Kindle e-books, those e-books must still be fitted within the constraints of their parent app, e.g., iBooks and Kindle.

The Web browser itself is an app. Web apps already allow us to present content without embedding it inside the visual frame of a browser window. Expect a time when the frame around e-book readers will be removed, too. Over the next couple of years e-book reading apps undoubtedly will edge closer and closer to incorporating a broader set of browser-like capabilities — most importantly full support for HTML5, CSS3, and JavaScript — so that the design and layout of e-books no longer must exist in the crippled state dictated by today’s iBooks and Kindle apps. But in that case: are e-books of the future anything other than Web apps?

She will come of age in a time when writing is not simply textual (though the careful use of words will persist…must persist). The world of 2030, when Mila is in college, will view one form of writing as a composition elegantly mixing many elements, among which will be words, images, sound, and video. A critical aspect in the coming decades is that the careful use and mixture of those elements must exist.

What do we call these compositions?

Those are not the books we cherish today Those are not e-books. They most definitely are not enhanced e-books. Neither are they documentaries. Technically, the compositions will be contained in some type of app. Maybe they’re just websites. Ultimately, they’re simply stories: narratives for examining the themes that engage civilization, compositions through which we learn and share our experiences of the lives around us.

(And the twenty-first century form of storytelling is as much about the reader as it is about the author.)

A word loosely tossed around these days by media companies is content. Content is often defined by the container. Book necessitates text, perhaps joined by the occasional image. What about other containers? For instance, documentary films necessitate motion images joined with voice-over narration. With the iPad possibilities exist for a hybrid exhibiting capabilities not found in either print or film.

Feeding the reading space of 2030, through whatever magical hardware brand dominates the delivery of digital media, will be apps that are hybrids of books and documentaries.

If we think of the iPad, though, as supporting a new genre then we should step back to examine the whole experience of reading, even asking what is non-fiction? (For the sake of this discussion I leave fiction for another day.) Why do people read and spend time with non-fiction books? Ultimately, I suspect the answer revolves around learning. The desire to learn prompts us to read and, preferably, have an enjoyable experience while doing so. Similarly, that desire to learn in a satisfying manner drives us to view documentaries.

The challenge is in exploring how to leverage the tablet platform for storytelling. The iPad brings a new way of reading. Likewise, it carries forward a new way of writing.

While the publishing community scrambles for today’s solutions, the real burden is on all of us to ensure that tomorrow’s writers & editors understand the elements of style required for creating the publications that will dominate the mid-century. My daughter will be less than forty years of age in 2050. Aspects of the world will be unthinkably different then. Much will remain the same, but the way humans communicate through media will continue its long trajectory. Perhaps what we’re doing now with apps will someday appear as quaint as magic lanterns or the early years of cinema. Undoubtedly, the techniques of writing and composition in a tablet-based digital environment will evolve with time, eventually forming accepted practices that support different types of reading experiences.

And her mom Ceci promises to do more blogging about book design soon.

We’re primarily interested in the development and design of book apps. Yes, that’s a broad category ranging from e-books to apps that don’t even resemble the traditional notion of a book.

But also we’re still designing printed books. Despite all the euphoria over e-books and apps, the demand for traditional book design hasn’t slowed a bit.

We also just have a really strong interest in where the book as app is heading. Soon I’ll be sharing my adventures with developing on the iPad/iPhone platform and previewing some of the books apps that we’re working on.