I have been working on a story: “As a user, I should be able to search for hotels around a given location so that I can add the hotel to my trip.”.

I built my basic form for the user to fill out the location information and provided my awesome continue button to get hotels:

I quickly realized that the user’s location could be resolved to more than a single place. If the user entered in county: US and then city: Greenville, there would be 10 or so matches. I would need the user to choose which was the correct city. One way to do this would have been to take the user to a new UITableViewController with all the matches and ask the user to choose a match, then pop then continue on to find the hotels around the selected location. While this would work, I dont like it. What if it worked like Google Maps? The Google Maps application shows the user a UIAlertView with an embedded TableView. It’s pretty clean. It works well because the user does not need to go to a separate page to choose a location match. I want my user to have this same experience.

If you have used the UIAlertView much, you know it is very limited on custimization opportunity. I decided to subclass UIAlertView to build my new location selector. I ran into a few “a ha” moments when trying to mimic the Google Apps look and feel. First, their UIAlertView has rouned top and bottom corners that are independent of the TableView. They are actually using a PlainStyle TableView and when you scroll the table in the alert, the table looks like it is sitting inside of a rounded rect UIScrollView. Tricky Indeed!

Our solution was to use some transparent rounded corners with a dropshadow on the top image. We also wanted the height of the custom alert to be dynamic based on the size of the embedded UITableView. However, UIAlertViews do not have a frame or height property. The height of the UIAlertView is based on the length of its message property. Our solution to this problem was to identify the number of rows in the table and add return characters to the message property of the UIAlertView.

Here is what it ended up looking like:

I have been working on providing an “Offline” mode for TripCase.  TripCase’s strength is its ability to organize mounds of data so that you, the traveler, can look to one place for your travel data.  While that’s all awesome and cool, it introduces a pain in managing that data while you are “disconnected” from your favorite carrier or are not in the range of your favorite coffee house wifi.

Our approach for TripCase is to cache data as its received to the phone.  So if you have seen the weather, or looked at your trip, or added posts to your TripLog, etc.  we store the last received inormation on the phone.  When you start the phone, we check for network connectivity and if we are unable to get a connection, we push you into our Offline Mode.  The UI changes slightly with a simple logo treatment letting you know you are now in offline mode.  Your trips and the surrounding data is there for you to view.  This allows you to open up TripCase while in flight or while disconnected and still get your last known information regarding your trip.  Also as a bonus, we actually send the iPhone more messages than we show you on your Main tab.  This allows us to deliver messages to you while offline.  Its really an “Almost Online” feature rather than Offline.

We also protect you from performing actions that are not allowed in Offline mode. Since you are disconnected, you should not have the ability to change your data (i.e. delete your trip, add a new TripLog entry, delete trip segments, etc.).  We alert you when you attempt to perform an action not allowed in Offline mode.

Offline is going to allow our customers to utilize our app whether they are connected or not.  To some, it will be almost transparent and possibly not even noticeable.  We hope they get a “wow how did I get a message while in Offline” feeling as they see new messages show in their Main tab while in flight.

So we’re days away from final submission to Apple. We’re pretty excited, tired, anxious and giddy all at once.

Our team has spent several months on iteration planning, design mocks, copy points and branding. We just want it live already! Having a third party be *the* dependency on go/ no-go is unusual for us, so it’s been a good learning experience.

Our beta testers have given us valuable feedback and have helped mold the final features you’ll see day 1 on iTunes.

Although iTunes Store states that all sales are final, dissatisfied customers can plead their case to Apple and possibly get a refund. When that happens, you see it reflected on your daily sales trends reports as negative units sold.

If you see a lot of those, that means that there is a problem. Usually the sales volume and customers’ rantings in the review section are better indicators of the quality of your product. Negative units sold just add insult to injury.

When I found out I was going to have the opportunity to design an iPhone application, I jumped at the chance. While I’ve designed mobile phone applications, they were browser-based (which was a unique challenge of its own) .

The challenge of the iPhone application was primarily to get myself into a completely new mode of human-to-device interaction. From the touch -screen technology to the strict guidelines outlined in Apple’s 150-page iPhone Human Interface Guidelines, I had my work cut out for me.

Not to mention that we had a grand-scale idea that, at the same time, would have to be broken down into tasks with an average of two- to-three-step interaction flows.

What could be more fun?

Here’s my list of the top things that make UX development for the iPhone relatively easy:

A pre-made UI kit. Actionable items, navigation locations, and various types of information viewing modes (tables, lists) are pre-determined on the iPhone. All you have to do is figure out which one will work best to suit each feature.

1. A limited number of items in the UI Kit. This forces you into designing features and functionality that conform closely to other applications, therefore maintaining that wonderfully consistent iPhone standard. The learning curve from application to application is very low due to this, and users can jump right in.
2. The high level of detail provided in the HIG document pretty much gave me a laundry list for every challenge I would face, making my UI designs essentially plug-n-play.

And, conversely: the challenges I discovered along the way in designing for the iPhone:

Getting into a new mode of thinking: touch-screen, tiny views, limited flows, and users who are in a hurry: they’re not wasting time on the computer at home in the evening, they’re on the go: traveling, in transit, in the middle of doing other things (standing on line for a latte!)  and they want to accomplish tasks with little to no wait time.

My Best Recommendations for iPhone UX Design

Read the HIG.

1. Read the HIG.
2. Read the HIG. Okay, you get the point.
3. Don’t deviate from the standards outlined in the HIG.
4. Get your features nailed from the first.
5. Get your flows in order with pencil and paper first.
6. Don’t start design until you’ve worked with development on a skinless prototype to make sure everything you want to do is going to work.
7. Keep your design simple and clean.

And that’s it! Happy designing!

When someone asks a pregnant woman when she is due the answer is simple. The due date, while not an exact prediction, is a rather straight forward formula that doesn’t vary from pregnancy to pregnancy.  We don’t have the choice of extending the birth date until the nursery is completed, or until all the announcements have been sent, or until the baby is finished teething and can sleep through the night!

Unfortunately, is not as easy to define the gestational process for a new product .  The decision to wait on a launch versus building just one more feature can be never-ending decision process.  There is a fine line that separates having what you need to hook users and getting a product to market.  If you don’t strike the right balance between the two halves, it could mean trouble for the product.  I’ve found that if the product isn’t what users want, many will simply not come back because there are so many other options.  On the other hand, I’ve also found that if you miss the boat on timing, you can have a difficult time attracting users who have already started to use a competitive product (even if it isn’t has cool as yours)!

I’m so excited about our new iPhone travel app and I think we have nailed the right mix of cool features and timing.  I’ve had the opportunity to utilize our product as a traveler would and I absolutely LOVE it (that isn’t just the biased mother in me speaking)!!!!

Others writers here have mentioned that TripCase reflects our belief that TripCase can make travel better.  That there is information and technology that travelers need on the road today, and isn’t.

But TripCase started out as just a concept, that we could make travel better.  But the question quickly became “How?”.

The first answer is obviously to use mobile devices.  But many attempts have been made to deliver capabilities via phones, and most if not all have failed.  So why did we start there?  The short answer is the iPhone.

When an existing app is updated with a new binary, you will notice in the following days a large amount of units sold with zero royalty. When that happens, don’t freak out. It’s good! That means that: a) people haven’t deleted your app, and b) they cannot wait for the next update.

One crude measure of customer satisfaction.

Apple’s review process has seen  dramatic improvements in 2009. The review team is more responsive now.
For those who are not familiar with the submission process to ITunes Store, here is a summary of the steps involved:

1) The development team uses a software package called XCode to build a binary of the application with appropriate signature.
2) The application is then compressed and uploaded to Apple’s iTunes Connect site. In addition to the compressed binary, a 512×512 image representing the app on ITunes Store must be uploaded. A scaled-down (57×57) icon of the same image must be used by the application as an icon on the customer iPhone home screen. An Additional five snapshots of the app can be uploaded. These images will be used by users browsing the store to get a feeling of the app.
3) Description of the app (for every localization) is also required in this process.
4) The price and geographic distribution (Only US, Global, etc.) is also required.

After providing this information, the app can be submitted for review.

At the time of this writing, Apple usually respond within a week. I have noticed that they work weekends! Well, at least Saturdays. If you’re lucky, you don’t hear from the review team at all. Instead, you receive a wonderful message saying: “Dear John Doe, The status for the following application has changed to Ready for Sale.”
It takes less than three hours from the receipt of this email for the app to show on the iTunes Store.

If, on the other hand, the review team is not happy with some aspect of your app, you receive a snapshot of the screen having the problem with a reference to a section in the iPhone’s Human Interface Guideline document, such as the following:

“Please review the Handling Common Tasks section of the iPhone’s Human Interface Guideline here:
<https://developer.apple.com/iphone/library/documentation/UserExperience/Conceptual/MobileHIG>”

You fix the problem, and submit a binary again. You do not need to change other aspects of the submission if the problem is in the app itself.  If the review team finds another problem, they respond back (within a week) with another snapshot and another section to read.

This process repeats, until you give up, have a heart attack,  or you receive “Ready for Sale” email.
Sorry, you don’t receive a list of issues before hand. One issue at a time!

You can change the price of the app, its description, etc., anytime after the app appears in the store. A new binary however, requires that you go through the process again. Once a revision is approved, the old version is removed and is replaced by the new one. This swap is not instantaneous;  no sales for about three hours!

Currently, 17,000 apps in 20 categories are available. Unless your app simulates body sounds, good luck getting noticed.

So alpha testing is very strong with the app getting high scores from testers. Lot’s of good enhancement requests and feedback that will make public launch rock!

We’re opening it up now for private beta. We’ve selected a few hundred of our closest friends to participate but if you want it, drop us a line and we’ll get you on the list.