Archive for February, 2009

iPhone UX Challenges and Preferences

Thursday, February 19th, 2009

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.

  • Restrictive use of the components in the UX Kit. For example, you must always place certain types of interaction in the same place, and you cannot add interaction that the UI Kit doesn’t currently support (without a lot of hassle) . So when you’re looking, for example, for a way to provide a user with more than three actionable options, you are limited.  

  • Put your creative solutions back in the box. If you’re an out-of-the-box thinker when it comes to design, you’re going to have to climb back in. Apple wants you to use the tools they give you, period. Don’t create new or innovative ways of attacking a problem – follow the provided solutions, and make one of them work. For me, this was really hard. Why doesn’t Apple want my great ideas? Okay… maybe they do, but they would prefer that we are consistent.
     
  • Back to the Drawing Board: if you can’t make one of the UI kit’s approaches to a problem work,  you’re going to have to go way back to the drawing board, and break down any interaction flows you may have created that, um, creatively circumvented – or outright ignored!—any of the HIG standards.  

  • Visual Design Limitations: while that might be a dream for a development team short on visual designers, it’s a bit of a disappointment for the design team. Getting colors, gradients or patterns into the overall look and feel of the iPhone isn’t as easy as  code.css  { color: #4b0082 } . It takes developers a few backflips (and maybe even a few hacks) to get a remotely complex color scheme into the interface, so design with caution, and expect to have to go back and re-visit your look and feel after conferring with developers.
    1.  

    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” is when?

    Monday, February 16th, 2009

    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)!!!!

    Why the iPhone?

    Friday, February 13th, 2009

    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.

    Product Updates and the Royalty Column

    Friday, February 6th, 2009

    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 submission

    Tuesday, February 3rd, 2009

    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.

    Private beta here we come

    Tuesday, February 3rd, 2009

    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.