Jan 18, 2013
We’ve had little time to blog in the last couple of years. A young daughter and a lot of work fills the days & nights. Here’s a brief recap of some of our current & notable past projects (images upcoming in future posts for many of these projects).
The design and development of two iPad apps for BelMontis Publishers. These are both children book apps:
* Rom and the Whale of Dreams
* The Little Sand Bear
The design and development of an iPad app for boutique hotels
* Phileas Fogg boutique hotels
Book designs in progress:
* It Girl 4 Life by Tamara Branch
* Edgy Conversations by Dan Waldschmidt
* Nestlé: 100 Years in Egypt (for Nestlé Egypt)
Completed in 2011 – 2012
app design & development
* Stray Boots iPhone app
* Recoleta Cemetery iPhone app
* Buenos Aires in 4 Days iPhone app
book design (not a complete listing)
* InsideOut Enneagram: The Game-Changing Guide for Leaders. 100% Fresh by Wendy Appel. Palma Publishing
* Eve’s Breast by Calvin Luther Martin. K-Selected Press
* Keepers of the Black Stones by P.T. McHugh. Glass House Press
* Upgrade to Free: The Best Free & Low-Cost Online Tools and Apps by Beth Ziesenis. TSTC Publishing
* The RV Centennial Cookbook: Celebrating 100 Years of RVing by Evada Cooper. TSTC Publishing
* Lust, Violence, Religion: Life in Historic Waco by Bradley T. Turner. TSTC Publishing
* Wide Awake & Dreaming: A Memoir of Narcolepsy by Julie Flygare. Mill Pond Swan Publishing.
* Tantra, the Play of Awakening by Shambhavi Sarasvati. Jaya Kula Press
* 20 Years Later by Emma Newman, Dystopia Press
* How to Become a Superhero: The Ultimate Guide to the Ultimate You! by Michael Sage, Superhero Press
* Despite Lupus: How to Live Well with a Chronic Illness by Sara Gorman, Four Legged Press
* She’s Six Steps Away by Eric Disco
* Data Dynamite: how liberating information will transform our world by W. David Stephenson,
* The One by Cheryl Robinson, Rose-Colored Books
* Who Will Care When You’re Not There? Estate Planning for Pet Owners by Robert E. Kass, Carob Tree Press
* prototype design of MyTime series for Acco/Mead
* facsimiles of 19th century documents inserted in the page layout of the novel The Transformation of Bartholomew Fortuno by Ellen Bryson. Henry Holt and Co.
Ceci promises that she will soon get back to blogging about book design. Here are a few links to some her previous posts that you shouldn’t miss.
If you’re interested more in what I’m doing then follow my fairly new blog Endless Hybrids where I write about creativity, learning, and leisure in the age of mobile computing and Internet TVs.
Oct 8, 2011
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.
Oct 4, 2011
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.
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:
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.
Sep 29, 2011
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?
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.
Sep 28, 2011
Midway through my professional life is a good time to pause and reflect on what fills my days and nights. And it all revolves around books.
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.