More than ever, designers are being asked to create experiences for a variety of mobile devices. As tablet adoption increases and we move into the post-PC world, companies will compete for users’ attention with the quality of their experience. Part of designing successful apps for Android tablets requires not only a great concept that will encourage downloads, usage and retention, but also an experience that Android users will find intuitive and native to the Android environment.

The following will help designers become familiar with Android tablet app design by understanding the differences between the iPad iOS user interface and Android 3.x “Honeycomb” UI conventions and elements. We will also take a look at Honeycomb design patterns and layout strategies, and review some of the best Android tablet apps already out there.

Note: While Android 2.x apps for smartphones can run on tablets, Android 3.0 Honeycomb was designed and launched specifically for tablets. Future updates promise to bring Honeycomb features to smartphone devices in addition to making it easier to design and build for multiple screen types.

For most of us, our first exposure to tablets was via the iPad. For this reason, it’s reasonable to begin comparing the two user interfaces. By comparing, we can align what we’ve already learned about tablets and begin to focus on what important differences there are to meet the unique UI needs of Android users. This not only helps us get up to speed, but becomes especially important when designing an Android tablet app from an existing iPad one.

It’s just like the iPad, right?

While the Android tablet and iPad experience share many similarities (touch gestures, app launch icons, modals, etc) there are also many differences that designers need to be aware of before making assumptions and drawing-up screens.

Screen Size and Orientation

The biggest difference between the two platforms is the form factor. Layouts for the iPad are measured at 768 x 1024 physical pixels and the iPad uses portrait mode as its default viewing orientation.

With Android tablets it gets a bit more complicated due to multiple device makers. In general, there are 7” and 10” Android tablets screen sizes (measured diagonally from top left corner to bottom right corner) and sizes in between. However, most tablets are sized at around 10”.

What does this mean in pixels? A good baseline for your layouts is 1280 x 752 (excluding the System Bar) based on a 10” screen size using landscape—not portrait—as the default orientation. Like the iPad, content on Android tablets may be viewed in both landscape or portrait view, but landscape mode is how it’s generally used.

Viewing a web page on both Android Tablet and iPad in portrait mode

Viewing a web page on both Android Tablet and iPad in landscape mode

However, for Android screen size is only half of it. Android tablets also come in different ‘screen densities‘ — that is the number of pixels within a physical area of the screen. Without going into too much detail, designers must prepare all production-ready bitmaps for three different screen densities by scaling each bitmap 1.5x and 2x its original size so that a bitmap originally set at 100 x 100 pixels also has copies at 150 x 150 and 200 x 200. By making three batches of graphics scaled at these different sizes, you will be able to provide any necessary bitmaps for medium, high and extra high density tablet screens without losing image quality.

Note: For more information on screen densities and graphics preparation for Android devices, refer to my previous article on Designing for Android.

System Bar

While iOS makes minimal use of the System Bar, Android Honeycomb expands its size to include notifications and soft navigation buttons. There is a Back button, Home button and a Recent Apps button.

The Android Honeycomb System Bar and buttons are always present and appear at the bottom of the screen regardless of which app is open. Think of it as a permanent UI fixture. The only exception is a ‘Lights Out Mode’ which dims the system bar for showing immersive content such as when playing a video or game.

Back Button

While the bulkiness and permanence of the Honeycomb System Bar might appear as an obstacle to designers, it has the advantage of freeing-up real estate typically taken by a ‘Back’ button in apps for the iPad. The Honeycomb System Bar has a ‘Back’ button that works globally across all apps.

Action Bar

The bulk of the UI differences between platforms is concentrated in the top action bar. Android suggests a specific arrangement of elements and visual format for the tablet Action Bar that includes placement of an icon/logo, navigation (e.g. drop-down menu or tabs), and common actions. This is one of the most unifying design patterns between different Android Honeycomb apps and worth taking the time to familiarize yourself with before attempting customization or something iPad-like. More on the pervasive Action Bar later.

Widgets

New to iPad users will be Android’s widgets. As the name describes, they are small notification and shortcuts systems users can set to appear on their launch screen. Widgets can be designed to show stack views, grid views, list views and with Android 3.1, are now re-sizable.

Notifications

While iOS’s notifications push simple alerts to your launch screen, Honeycomb offers rich notifications that pop up (“toast” we used to call it) at the bottom right area of the screen much like Growl on Mac OS X. Custom layouts for notifications may include anything from icons to ticker text and actionable buttons.

Settings

Most often, any settings within an iPad app are presented from a popover triggered by an ‘i’ button. Settings categories are broken up into tables for easy visual separation. Honeycomb has a different convention that looks more like the iOS General Settings screen with the ability to navigate categories on the left and view detail on the right. This is the preferred (and more elegant) way of presenting multiple settings in Honeycomb.

UI Elements

As you can imagine, Android goes to great lengths to do everything opposite its competitor (that’s called differentiation!). Honeycomb has its own UI conventions and new ‘Holographic UI’ visual language for such mundane actions as picking a time/date, selecting an option, setting volume, etc. It’s important you understand this UI language for building screen flows and creating layouts.

Fonts

Question: How many fonts does iPad 4.3 allow you to use?

Answer: 57

Question: How many does Android?

Answer: 3

Yep, that’s Droid Sans, Droid Serif and Droid Sans Mono. However, there is an upside: While that’s all you get with the platform, designers and developers are free to bundle any extra fonts with their app.

Anything the same?

Luckily for designers already familiar with the iPad, there are some similarities between the two platforms:

Touch Gestures

Tap, double tap, flick, drag, pinch, rotate and scroll at will.

Split View and Multi-pane UI

Split View is one of the most commonly used layouts for tablets consisting of two side-by-side panes. Of course, you can design additional panes for more complexity.

Embedded Multi-Media

Both platforms allow embedded audio, video and maps.

Clipboard

For copying and pasting data in and out of separate applications.

Drag-and-Drop

Both platforms have drag-and-drop capabilities.

Design Patterns

Honeycomb carries over many of the same design patterns introduced in Android 2.0 and expands on them. In case you’re not familiar with design patterns, Android defines them as a “general solution to a recurring problem.” Design patterns are important UI conventions designed by Android to help unify the user experience and provide designers and developers a template to work from. They are also customizable, so no need to fret!

As mentioned before, the Action Bar is the most prominent Android UI component and the one we’ll focus on.

Icon/Logo

The Action Bar begins with an icon or logo on the far left and is actionable. By tapping on it the user will be directed to the app’s home screen.

Navigation

Next, we typically find some mode of navigation in the form of a drop-down or tab menu. Honeycomb uses a triangle visual to indicate a drop-down and a series of underlines for tabs which typically take up the majority of the Action Bar real estate.

A left arrow button may also appear to the left of the icon/logo or label for navigating back or canceling a primary action.

Common Actions

Common Actions are as their name implies providing the user with such things as search, share and an overflow menu. They are always placed on the right side of the Action Bar away from any tabs.

Overflow Menu

The Overflow Menu is part of the Common Actions group and is sometimes separated by a vertical rule. The purpose of the Overflow Menu is to provide a place for miscellaneous menu items such settings, help, feedback, etc.

Search

Search is also a part of the Common Actions set. Unique to Search is its expand/collapse action. Tap on the Search icon and a search box expands out for entering your query. Tap the ‘x’ button to cancel and it collapses to its single button state. This is a space saver when you already have many actions or tabs you need to show.

Contextual Actions

Contextual Actions change the format of the Action Bar when an item is selected to reveal actions unique to that selection. For example, a photo app’s screen of image thumbnails might have an Action Bar that changes once an image is selected. In this case, the Action Bar might change to show contextual actions for editing that particular image.

To exit the Contextual Action Bar, users can tap either ‘Cancel’ or ‘Done’ appearing in the far right area of the bar.

Tablet Layout Strategies

Using Fragments and Multi-Pane Views

The building blocks of Honeycomb design are Fragments. A Fragment is a self-containing layout component that can change size or layout position depending on the screen orientation or size. This further addresses the problem of designing for multiple form factors by providing designers and developers a way to make their screen layout components elastic and stackable depending on what screen restraints the app is working with. Screen components can be stretched, stacked, expanded or collapsed and shown or hidden.

What makes Fragments so special? With a compatibility library, developers can bring this functionality to Android smartphones back to Android 1.6, giving designers and developers the option of building an app using a one-size-fits-all strategy. In short, this will allow designers and developers to build one app for everything.

While Fragments may be a term used more by developers than designers, it’s good for designers to adopt the perspective that capsules of content can be stretched, stacked, expanded and hidden at will.

The most common arrangement of Fragments is the split view. This layout is common for news apps and email clients where a list is presented in a narrow column and a detailed view in a larger one.

Another way of presenting a split view is to turn it on its side. In this case, the sideways list Fragment becomes a carousel, navigating horizontally instead of vertically.

Orientation Strategies

While use of Fragments is great for applying one design to multiple screen sizes, they are also useful for setting orientation strategies. Your screen design might look great in landscape but what are you going to do with three columns in a narrow portrait view? Again, we have the option to stretch, stack or hide content. Think of Fragments like a bunch of stretchy puzzle pieces that you can move around, shape or eliminate as needed.

A Word About Animation

The Honeycomb framework allows designers and developers to use a variety of animation effects such as “fades or movement between states, loop and animated image or an existing animation, change colors, and much more.” Honeycomb also boasts high-performance mechanisms for presenting 2-D and 3-D graphics. For a good overview of what Honeycomb is capable of, check out this video.

Learning from Example

Designing apps for Android tablets is still relatively a new space with some brands beginning to test the waters. Below is a list of apps for inspiration. You can download any of the apps from Android Market or Amazon.com.

YouTube

Naturally, Google’s YouTube for Honeycomb is an exemplar app showcasing all the design patterns and UI elements discussed above. To get a real feel for Honeycomb, download this app first and take it for a spin.

CNN

The CNN app makes good use of touch gestures (flicking to view additional content), split view and fonts! In this case, they’re using a custom font (Rockwell) for news headlines.

CNBC

Another good news app with examples of animation (stock ticker tape) and rich graphics and gradients. CNBC has one of the most visually compelling apps.

Plume

With it’s three column layout, Plum is a good example showing how layouts may need to change dramatically from landscape to portrait views.

FlightTrack

A data-heavy app done elegantly. Includes nice examples of maps, subtle use of animation, and standard Honeycomb UI elements.

Pulse

What else can you say…it’s Pulse for Android tablets! It’s still fun to compare the Android tablet version with the iPad one which is identical in almost every way.

WeatherBug

This was one of the first Honeycomb apps in Android Market and makes good use of maps and the Holographic UI for showing pictures from weather cams.

Kindle

Kindle pretty much sticks to the books when it comes to using design patterns and Honeycomb UI elements. Nevertheless, the outcome is very elegant while staying true to Android’s best practices.

Honorable Mention

IMDb
News360
USAToday
AccuWeather
Ustream
Google Earth
Think Space
Gmail

Online Resources

Videos

Designing and Implementing Android UIs for Phones and Tablets (Google I/O 2011)

Android 3.0 Honeycomb Animation Demo

Presentations

Designing and Implementing Android UIs for Phones and Tablets (Google I/O 2011)

Blogs

Tablet UI Patterns

Android Developers

Supporting Multiple Screens
Icon Design
Android 3.0 Platform Highlights

For designers, Android is the elephant in the room when it comes to app design. As much as designers would like to think it’s an iOS world where all anyone cares about are iPhones, iPads and the App Store, nobody can ignore the fact Android currently makes up the majority of the smartphone market share and is being used on everything from tablets to e-readers . In short, the Google Android platform is quickly becoming ubiquitous and brands are starting to notice.

But let’s face it, Android’s multiple devices and form factors make it feel like an uphill battle to design for, and its cryptic documentation is hardly a launchpad for designing and producing great apps. Surf the Web for resources on Android design and there’s little there to guide you.

If all this feels discouraging (and maybe the reason you’re not designing apps for Android), you’re not alone. Fortunately, Android is beginning to address the multiple device and screen size issues, and device makers are slowly arriving at standards that will eventually reduce any complexity.

The following article will help designers become familiar with what they need to know to get started with Android and delivering the right assets for development. Topics include:

• Demystifying Android screen densities
• Learning the fundamentals of Android design via design patterns
• Design assets your developer needs
• How to get screen shots
• What Android 3 is about and what’s next on the horizon

Android Smartphones and Display Sizes

When starting any digital design project, it’s a good idea to have an understanding of the hardware first. For iPhone apps, it’s either the iPhone or iPod Touch. For Android, it spans dozens of devices and makers. So, where to begin?

The old baseline for Android smartphone devices was the T-Mobile G1, the first commercially available Android-powered device which has an HVGA screen measuring 320 x 480 pixels.

HVGA stands for Half-size Video Graphics Array and is the display size for many of today’s smartphones (the iPhone 3GS, 3G and 2G use this configuration).

To make things simple, Android divides physical screen sizes (measured as the screen’s diagonal from top left corner to bottom right corner) into four general sizes: small, normal, large, and xlarge.

320 x 480 is considered a normal screen size by Android and for xlarge, think tablets . However, the most popular Android smartphones out today have WVGA (Wide VGA) 800+ x 480 displays. So, what’s “normal” has changed. For now, we’ll say that most Android smartphones have large screens.

The variety of display sizes can be challenging for designers trying to create one-size-fits-all screen layouts. I’ve found the best approach is to design one set of layouts for 320 x 533 physical pixels and then introduce custom layouts for the other screen sizes.

What You Need to Know About Screen Densities

But screen sizes are only half the picture! Developers don’t refer to a screen’s resolution but instead, its density. Here’s how Android defines the terms in its Developers Guide:

Resolution
The total number of physical pixels on a screen.

Screen Density
The quantity of pixels within a physical area of the screen; usually referred to as dpi (dots per inch).

Density-independent pixel (dp)
A virtual pixel unit that you should use when defining UI layout, to express layout dimensions or position in a density-independent way. The density-independent pixel is equivalent to one physical pixel on a 160 dpi screen, which is the baseline density assumed by the system for a “medium” density screen. At runtime, the system transparently handles any scaling of the dp units, as necessary, based on the actual density of the screen in use. The conversion of dp units to screen pixels is simple: px = dp * (dpi / 160). For example, on a 240 dpi screen, 1 dp equals 1.5 physical pixels. You should always use dp units when defining your application’s UI, to ensure proper display of your UI on screens with different densities.

It’s a bit confusing, but this is what you need to know: Like screen sizes, Android divides screen densities into four basic densities: ldpi (low), mdpi (medium), hdpi (high), and xhdpi (extra high). This is important because you’ll need to deliver all graphical assets (bitmaps) in sets of different densities. At the very least, you’ll need to deliver mdpi and hdpi sets for any smartphone apps.

What this means is all bitmap graphics need to be scaled up or down from your baseline (320 x 533) screen layouts (note: there is also a method for parsing SVG files that provides a way to scale vector art on different screens sizes and densities without loss of image quality).

The bitmap requirement is similar to preparing graphics for print vs. the Web. If you have any experience with print, you know that a 72 ppi image is going to look very pixelated and blurry scaled up and printed. Instead, you need to rescale the image as a vector image or use a hi-resolution photo and then set the file’s resolution at around 300 ppi in order for it to print without any loss of image quality. Screen density for Android works similar except that we’re not changing the file resolution, only the image size (standard 72 ppi is fine).

Let’s say you have a bitmap icon 100 x 100 pixels taken from one of the screens of your baseline app design. Placing that same 100 x 100 icon on a device with an ldpi screen will make the icon appear big and blurry. Likewise, placing it on a device with an hdpi screen will make it appear too small (due to the device having more dots/inch than the mdpi screen).

To adjust for the different device screen densities we need to follow a 3:4:6:8 scaling ratio between the four density sizes (for the iPhone it’s easy–it’s just a 2:1 ratio between iPhone 4 and 3GS). Using our ratios and some simple math, we create four different versions of our bitmap to hand-off to our developer for production:

• 75 x 75 for low-density screens (0.75x)
• 100 x 100 for medium-density screens (our baseline)
• 150 x 150 for high-density screens (1.5x)
• 200 x 200 for extra high-density screens (2.0x)*

*We’re concerned with only ldpi, mdpi and hdpi for Android smartphone apps

After you’ve produced all your graphics, you might choose to organize your graphics library as follows:

Note: There may be some confusion about what ppi (pixels per inch) you set your deliverables at. Just leave them at the standard 72 ppi and scale the image accordingly.

Using Android Design Patterns

Clients often ask whether or not they can use the same iPhone app design for Android. If you’re looking for shortcuts, maybe building an app for mobile web browsers using something like WebKit and HTML5 is a better choice. But for producing native Android apps, the answer is “no”. Why? Because Android UI conventions are different from iPhone.

The big difference with Android when compared to iOS devices is the use of the Back Key to navigate to a previously visited screen. The Back Key on Android devices is always present and available to the user apart from the app. It’s either a part of the physical device or digitally fixed to the bottom of the screen independent of any app (like what we see in the recently released Android 3.0 for tablets — more about this later).

The use of a Back Key other than within the app itself, leaves space for other elements at the top of the screen such as a logo, screen title or menu. While this navigational convention differentiates greatly from iOS, there are also other differentiators that Android calls design patterns. According to Android, a design pattern is a “general solution to a recurring problem”. Here are the main Android design patterns that were introduced with Android version 2.0:

Dashboard
This pattern solves the problem of having to navigate to several layers within an app. It provides a launch pad solution for rich apps like Facebook, LinkedIn and Evernote.

Action Bar
The Action Bar is one of Android’s most important design patterns and differentiators. It works very similar to the conventional Web site’s banner with a logo or screen title linking to a ‘home’ page typically placed on the left and common actions  buttons on the right. The Action Bar design is flexible with the ability to include hovering menus and expanding search boxes. It’s generally used as a global feature rather than a contextual one. Here’s an example of the Action Bar used by Twitter:

Search Bar
Allows a simple way to search by category and provide search suggestions.

Quick Actions
This design pattern acts similar to the iOS popover providing the user with additional contextual actions. For example, tapping a photo within an app might trigger a Quick Action bar to appear for sharing the photo.

Companion Widget
Widgets allow an app to publish notifications to the user’s launch screen. Unlike push notifications with iOS that act as temporary modals, Companion Widgets remain on the launch screen (tip: to select a widget for your Android device, simply tap and hold any empty space on one of the launch screens).

Using established design patterns are important for keeping your user experience intuitive and familiar to your Android users. Your users don’t want to have an iPhone experience on their Android device any more than a Mac user wants to have a Microsoft one within their Mac OS environment. So, understanding the design patterns is the first step toward learning to speak Android and designing an optimal experience for Android users. Your developer will also thank you!

Android design deliverables

OK, so I’ve designed my Android app and am ready to make it a reality. What do I need to hand-off to my developer? Here’s a quick list of deliverables:

1. Annotated wireframes of the user experience based on the baseline large screen size of 320 x 533 physical pixels. Include any additional screens for instances where a larger or smaller (320 x 480) screen size requires a modified layout or a landscape version is required.

2. Visual design mockups of key screens for WVGA large size (320 x 533) screens (based on a WVGA 800 x 480 hdpi physical pixel screen size) in addition to any custom layouts needed for other screen sizes.

3. Specifications for spacing, font sizes , colors and indication of any bitmaps.

4. Graphics library with ldpi, mdpi and hdpi versions of all bitmaps as transparent PNG files.

5. Density-specific app icons including the app launch icon as transparent PNG files. Android already provides excellent tips for designers on this topic along with some downloads including graphic PSD templates and other goodies.

How to Take Screen Shots

My product manager just asked for screen shots of the developer’s build. The dev is busy and can’t get them to me until tomorrow. Now what do I do? As of publication of this article, Android has no built-in way to take screen shots (bummer, I know). The only way is to just deal with it and that means pretending to be a developer for a while and downloading some really scary software. Let’s get started!

The following software must be downloaded:

1. All USB drivers for your Android device

2. Android software development kit (SDK)

3. Java SE software development kit (SDK)

Next, on your computer:

1. Extract the USB drivers to a folder on your desktop

2. Extract the Android SDK to a folder on your desktop

3. Install the Java SE SDK

On your Android device:

1. Open Settings (you’ll find it in the apps menu)

2. Tap on Applications

3. Tap on Development

4. Check the box for USB debugging

Now, for the fun part:

1. Connect your Android device to your computer via USB. Windows users: allow Windows to install all drivers. One of the drivers may not be found and will require you to go to the Window’s Device Manager under the Control Panel. There, you can locate the device (having a yellow warning icon next to it) and right-click on it.

2. If necessary, choose to update/install the driver for your device

3. Go to your desktop, open the Android SDK folder and select SDK Setup.exe

4. Allow it to automatically refresh its list of operating system SDKs available and select to install all packages

5. Once finished, exit the application

6. Go back to the opened Android SDK folder on your desktop and open the tools folder

7. Click on the file, ddms to open the Dalvik Debug Monitor

8. Select your device listed in the Name pane

9. In the application’s top menu, open the Device menu and choose Screen capture…. A Device Screen Capture window will open and you should see the launch screen of your Android device.

Navigating:

1. Grab your Android device and navigate to a screen of your liking. Go back to your computer and select Refresh in the Device Screen Capture window and the current screen from your Android device will appear.

2. If you’re on a Mac, you can just do the old shift-command-4 trick to take a screen grab or you can choose to copy it in Windows and paste it into one of the Windows media applications.

About Android Tablets

At CES 2011, companies launched a downpour of Android tablets with an array of screen sizes. However, after a quick review of the most popular Android tablets we can conclude that the most important screen size to focus on in physical pixels is 1280 x 800.

With the Android 3.0 “Honeycomb” release, Google provided device makers with an Android UI made for tablets. Gone is the use of a hard Back Key which was replaced by an anchored software-generated navigation and system status bar at the bottom of the screen.

Android 3.0 received an updated visual design and incorporates all the design patterns introduced with Android 2.0. One of the major differences with 3.0 is the Action Bar which has been updated to include tabs, drop-down menus or breadcrumbs. The Action Bar can also change its appearance to show contextual actions when selecting single or multiple elements on a screen.

Another new feature added to the Android framework with 3.0 is a mechanism called Fragments. A Fragment is a self-containing component within a layout that can change size or layout position depending on the screen orientation or size. This further addresses the problem of designing for multiple form factors by providing designers and developers a way to make their screen layout components elastic and stackable depending on what screen restraints the app is working with. Screen components can be stretched, stacked, expanded/collapsed and shown/hidden.

The next Android release scrumptiously dubbed “Ice Cream Sandwich” promises to bring this functionality to Android smartphones as well, giving designers and developers the option of building an app using a one-size-fits-all strategy. This could be a paradigm shift for designers and developers who will need to learn to think of app design in terms of puzzle pieces that can be either stretched, stacked, expanded or hidden to fit the appropriate form factor. In short, this will allow one Android OS to run anywhere (with infinite possibilities!).

A Word of Advice
Do get your hands on an Android phone and tablet and spend some time downloading apps and exploring their interfaces. In order to design for Android you have to immerse yourself in the environment and know it intimately. This seems obvious, but it’s always surprising to learn even the product manager doesn’t have an Android device.

Online Resources

Here are some links to online resources I found especially useful:

Presentations
Android Design Patterns
Android User Interface Design Tips
Excellence in the Android Experience

Videos
Android UI Design Patterns (Google I/O 2010)
Designing and Implementing Android UIs for Phones and Tablets (Google I/O 2011)

Documents
Comparison of Android Devices

Blogs
Designer’s Guide to Supporting Multiple Android Device Screens
Android UI Design Patterns
Android Patterns

Product Reviews
Best Android Phones (CNET: May, 2011)
Best Android Tablets (CNET: May, 2011)

Android Developers
Supporting Multiple Screens
Icon Design
Android 3.0 Platform Highlights

Other
Android App Developers GUI Kits, Icons, Fonts and Tools

With censorship and a recent refusal of a Google Voice app, the App Store hasn’t been without its controversies. It seems that Apple has been wrestling with the demands of developers and bloggers on one hand and the maintenance of their highly valued brand and business strategy on the other.

To try and address some of the issues on censorship of content, Apple has set up mandatory application ratings that work together with the iPhone’s restriction settings (Settings > General > Restrictions). They also have an unofficial approval process that includes the following:

• Applications must not duplicate the functions of the iPhone (such as another SMS interface or a home icon that looks too similar to a native app)

• Applications must not be of “limited utility”

• Applications must comply with some iPhone UI standards (e.g. don’t play with the phone’s vibration function)

• Applications must not be obscene or offensive (in other words, no profanity or pornographic content)

• Applications must not violate copyright infringement (i.e. repurposing someone else’s data)

The rejections of certain apps have caused the blogoshere to foam at the mouth and with the latest Google Voice rejection, some have even sworn to put down their iPhones until Apple changes its ways. While we would all like to see something as large as the App Store be as democratic as possible, Apple has no intention of letting go of the reins for a few rebel developers and for anyone following the Google-Apple marriage—the honeymoon is over. Unfortunately, in this case, Apple and AT&T’s business goals had to take precedent over their users’.

You won’t find a shortage of advice when it comes to App Store improvements. For the most part, it revolves around legitimate business concerns that effect developers and small businesses and can be summarized as follows:

1. “I have put countless hours and money into building an app for which Apple gives no guarantee if or when it will be published to the App Store.”

2. “The App Store is a massive black hole where I throw in my app, never to be found again.”

Issue #1 would be a concern for any entrepreneur. While most apps are approved in two weeks, building a product with no guarantee of entry into the only place where it can be sold, is risky business. This is even more critical for multi-person companies whose entire business depend on the success of their app. It also makes it extremely difficult for any PR planning. Not having a set launch date can hurt any much needed marketing efforts.

Apple provides developers an email for questions for their “App Review Team”, but with over 100,000 developers I’m skeptical that developers are receiving the feedback they need. Some developers are reverting to workarounds where they submit a prototype of their app with a launch date set far into the future. By doing this, they’re able to get a review of their app before spending more time and money on it. Nevertheless, they still end up waiting 2 weeks or more for feedback, putting a lull in their product schedule.

What’s needed is a better way for developers to get feedback on their apps before submitting it for approval. At the very least, Apple should have an FAQ blog to keep developers up-to-date with evolving standards. Clearer communication and more honesty on the part of Apple would help both parties save time and money.

The App Store as a big black hole seems to be the biggest problem facing developers, users, and Apple right now. Actually, it’s a black hole with a layer. The layer is the unbalanced promotion of gamer apps.

One blogger complained:

“Apple does not feature enough non-games in other categories in their “What’s Hot” and “New and Noteworthy” front page sections to incentivize other applications other than dollar games. A quick look in iTunes or in the App Store on an iPhone or iPod Touch will leave users the impression that Apple is all about games and not much else. We have run into this feeling from our customers who say their bosses are reluctant to let them buy software for their iPhones because they view them as toys. We’ve made the bet that the App Store is a better option than BlackBerry or Palm’s offerings but Apple needs to do more to demonstrate to professionals that it is for real.”

At last glance, the App Store home page promoted the following number of gamer apps:

• 7 of 8 apps under “New and Noteworthy”

• 8 of 10 for “Top Paid Apps”

• 6 of 10 for “Top Free Apps”

• 6 of 8 for “What’s Hot”

Everyone knows games are by far the most popular apps anywhere but unless you’re a gamer, promoting them so heavily on the home page isn’t useful and creates the perception that the App Store is mostly about games. The solution might be to create a separate “Game Store” (and possibly other stores for big categories such as books) that levels the playing field and provides more space for others to promote their apps at the home page level.

Another issue is the pricing structure. Charles Wolf of Needham & Company noted in his analysis of Apple’s July earnings report, “In some respects, the App Store has taken its place alongside YouTube, where poor taste is the defining metric. More ominously, it has led to a deterioration of the entire pricing structure for iPhone applications. The risk is that developers who hope to build quality applications that have a long shelf life may be discouraged from doing so because prospective development costs exceed the revenues they expect to earn on the applications. In short, this race to the bottom has the potential to degrade the overall equality of the applications sold at the App Store.”

Ge Wang of Smule Ocarina fame commented that he would “like to see a top app list that counted revenue instead of straight downloads, something he said would encourage more premium applications.” In short, there needs to be some way in which quality apps can rise to the surface and be discovered despite the possibility of having a more expensive price tag. Apple is in danger of becoming a receptacle for bad apps that cheapen the Apple brand and cover up more valuable applications like Wang’s Ocarina. Wang’s suggestion is a good one and could be taken a step further by creating a “quality” list based on not only revenue but also on user ratings.

Some other suggestions for the App Store include:

• Adding a Genius sidebar to the user’s Library Applications screen

• Making the App Store more similar to the Amazon.com experience with top reviewers, “Listmania!”, save to wish list/bookmark and a personalized homepage based on search results and purchase history

• Stop the proliferation of “Lite” versions by allowing apps to run for a specified amount of time

• Allow sellers to integrate an App Store module for purchasing apps on their own web site so developers and companies can offer their customers a more customized experience and better promote their other products.

• Replace “Staff Favorites” on the App Store homepage with something more meaningful like “Killer Apps” or “Genius Just For You”

• Give users the ability to filter search results

• Provide developers a better method for demoing their apps from the App Store. For example many developers like to publish video of how their app works which usually results in dark, out-of-focus YouTube videos. Apple could come up with a method for easily creating animated demos, giving developers an opportunity to show user flows and specific screen details in a coherent and unified way.

The Internet began to take off several years earlier with the introduction of Mosaic, the first Web browser with mass appeal. In 1994, the same founders formed a new company and released Netscape Navigator. Only a year later, Microsoft launched the first version of Internet Explorer and soon everyone was moving to the Web.

Flash forward to this century:

• January 2007, Apple announces the iPhone

• In June of the same year at WWDC 2007, Apple announces it will support third-party “web applications”

• In October, an open letter from Steve Jobs announces a software development kit (SDK) will be available to third-party developers

• November 2007, Google unveils the Android platform

• July 2008, Apple’s App Store officially opens with downloads topping 1.5 billion in first year
• April 2009, Blackberry App World launched

• June 2009, Apple vice president Phil Schiller announces there are 50,000 applications available in the App Store

• June 2009, Palm launches the Pre

• July 2009, Motorola, Huawei, Archos, Lenovo and HTC have already built or have confirmed plans to release a phone with Google’s Android platform

• July 2009, non-tech companies Taco Bell, Pizza Hut, Burger King , Coca-Cola, Nike, Adidas, Lacoste, D&G, Dior, BMW, Ferrari, Whole Foods, Kraft, and AAA all have iPhone applications

What’s going on? For some business owners, this might send shivers down their back. Is this for real? You bet it is, and you won’t want to be the last to know for the same reason you didn’t want to be the last to know about the Internet. Movement to mobile will be fast and as always, it’s the first to cross the finish line that counts, not the second.

Just as quickly as we turned into a culture with a computer in every home, we’re turning into a culture with one in every pocket. Not only are people walking around with little computers attached to their bodies, they are connected to them in a myriad of ways via online social networking, maps, news, games, video, music and chat.

This July at the VentureBeat’s MobileBeat conference, the BBC reported that the big prediction is that the mobile applications market will be as big as the Internet in 2020. It’s no surprise that they are also predicting the market will grow to 100,000 apps by the end of 2009. Ilja Laurs, CEO of GetJar commented, “The full blossom will come in ten years and mobile apps will become as popular as websites are today with consumers.”

Here are some reasons why you’ll want a mobile app for your business sooner rather than later:

If you’re not on the web already, then you’re dead. The same will hold true for mobile.

Just as it’s a requirement for most businesses to have a web presence, it will soon be one to have a mobile presence. For many businesses having no web presence would be death and holds true to the saying “out of site, out of mind” when it comes to staying connected with your customers. Not providing online content to your customers is a dead-end for them and with the price of advertising, no business can afford to throw away customer-generated interest. Mobile is no exception. It’s another extension to your customers. It’s 1999 all over again and you’re going to need a good mobile presence.

Mobile apps are an extension of your company’s brand

It’s no accident that brick and mortar companies like Taco Bell, Lacoste and Whole Foods have mobile apps. Mobile apps are another “touchpoint” for their brand where they can interact with their audience. Marty Neumeier in his book Zag writes, “Traditional advertising is in a death spiral”…”But the root causes for the death spiral are twofold: 1) People don’t like one-way conversations, and 2) People don’t trust advertising.”

So how do you extend your brand and not use advertising? One idea is to build a utility that your customers find useful…like a mobile app.

Sherwin-Williams designed ColorSnap for the iPhone to help their customers match colors they like with Sherwin-Williams paint color. Pizza Hut launched their iPhone app that lets their customers order their favorite pepperoni pizza in seconds. Pizza Hut promotes their app with words like “easy”, “fast” and “fun”. In short, they’re making it easy for their customers, and promoting their brand in a way that doesn’t come off as being intrusive or forceful. Best of all, their icon gets to live on the customer’s mobile device helping to establish a connection between Pizza Hut and their customers.

You will want to be connected to your customers wherever they go

Companies have found a multitude of ways to stay connected with their customers via TV, billboards, print ads, sponsorships, etc. Unfortunately for them, these mediums take on a static relationship with their customers when compared with mobile. Unless you have a logo tattooed to your body (I hope not), no medium goes everywhere your customer goes like a branded mobile application does.

Users don’t like to use their mobile web browser

Before Apple opened its App Store there was a lot of media coverage around increasing statistics showing the popularity of mobile internet usage.

That was then and this is now.

While having a web site optimized for mobile browsers is a good idea, it’s no longer a sufficient means of connecting with your mobile customers. Why? Because the experience doesn’t fit the medium. It’s slow and cumbersome and was originally designed for a PC experience, not your phone. For mobile users, speed is everything. Using a phone’s web browser is akin to using a knife instead of a Cuisenart to chop vegetables. One is automatic, one is not.

To use a browser on a mobile device the user opens it to a blank screen, types a long URL with their thumbs, zooms-in to be able to read the content and laboriously navigates via several zooms, pinches, swipes and taps. Basically, it’s a lot of work. Even optimized sites still require the user to type a URL and experience what is typically, a very generic, long and linear interface. In both scenarios, there’s also the frustration of waiting for long pages and big images to load. Why not make it easy for the customer to get the information they need within a few seconds?

When I want to read the New York Times I don’t go to their web site (which on my iPhone is little bit like reading a newspaper with a magnifying glass), I use my NYT app. When I want to track packages, I use an app for that. When I want to know what the weather is going to be like tomorrow, I use an app for that… The point is the mobile web browser is a tool of last resort. It’s a manual experience versus the “automatic” experience of apps.
_____

Of course moving your brand and/or company to the web 15 years ago wasn’t easy, and neither will moving it to mobile now. The good news is that some of the most successful apps are light in content and need only a few screens. Apps are typically widget-like and don’t require outsourcing half of India to get the job done.

The bad news is that there are now several platforms to design and build for, and each one uses their own programming style, visual language and screen dimensions (for more about this topic and why “one size doesn’t fit all”, please view my previous blog post: 31 Flavors – Designing for iPhone, Android and Blackberry Platforms). While the iPhone seems to be leading the pack in regard to app usage, you cannot ignore Blackberry’s user base or the number of “Android phones” in the works.

The miniature size of apps compared to desktop applications and web sites has its advantage. A disadvantage is that users quickly lose interest. That’s why it’s important to continue to keep users and customers engaged via dynamic content, updates and new apps.

Another point to keep in mind is that despite an app’s limited number of screens, the time and cost it takes to launch a successful app isn’t cheap and takes several weeks. There are still, only a handful of good mobile app designers and developers out there. The ones that do exist are still learning on the job because the technology is still new and platform updates are frequent. In addition, the development might require two engineers if any animation outside of the SDK is used. An app, while deceptively small in size, can be extremely feature rich and challenge both designers and technologists to maintain a user experience that is efficient and at the same time, meaningful for the customer.
_____

If you’re shopping for an app team to help you, this is what you should look for:

Multidisciplinary team

While some single-person development teams have been successful building and launching their own apps, with over 50,000 apps in Apple’s App Store alone, the gold rush is over and it’s not recommended that you try to hire one person to do everything. It takes several people to launch a successful app including, in most cases, an interactive designer, a visual designer, an engineer and a project manager.

An understanding of the medium

Designing for the iPhone or Android platform is not the same as designing a web site. The designers should have intimate knowledge of the device or platform with a thorough understanding of its native elements and best practices. User interfaces should be designed to be intuitive and follow platform standards that the device’s users are accustomed to. For example, iPhone apps don’t use drop-downs. A good iPhone app designer will be able to provide an immediate solution for such a problem.

Documentation

Make sure the team has an iterative design process that includes documentation of user flows and screen details (i.e. wireframes). Paper is cheap. Make sure the team has worked out most of the design problems on paper before any coding begins. Apple’s UI Evangelist, Eric Hope recommends that at least ½ of an iPhone project’s time be spent on design.

Lastly, keep in mind that mobile apps are still a new medium, mobile platform updates are frequent and the rules of the game and its players are constantly changing.

So, maybe you’re asking: how do you design for three different mobile platforms without losing your marbles?

Before starting on each project, I did my homework to see what other designers and developers have done in the space. For Android and Blackberry, this study was not only a nice-to-have, it was a requirement. While Apple has a reasonably good human interface guidelines to shepherd designers and developers through putting together a consistent and intuitive interface for iPhone users, the other two leave a lot to be desired.

Google, ironically, preaches the value of using consistent UI components without ever really sharing what those components might be to any great extent. They have an in-depth tutorial on how to create icons but don’t mention much on what the other standard UI components should look like. This leads designers to go off on their own and create what they think is right for the Android UI versus Google suggesting what the best practices are. This could easily be solved by providing a comprehensive style guide.

What’s the purpose of doing this? The purpose is to understand the personality, interaction and visual language of a platform so that the designer is able to design an interface that users already visually and interactively understand. The users understand and intuit this language based on previous experiences with the platform’s native apps and/or other downloaded apps. This is why an iPhone app should look and feel like an iPhone app and an Android app should look and feel like one of its own. Differentiation is important where there’s competition, but without any consistent use of native UI elements, the user is at a loss with the interface and has to learn something new costing them time, effort and frustration.

Some companies take the easy route. They simply take any graphics and user flows they created for one platform (typically the iPhone) and adapt it to the new one. Because of Android’s lack of support (and perhaps because of the developer’s lack of interest), we see a lot of this being applied to its apps. This is not only bad for Android’s effort to provide a consistently intuitive user experience but it’s also, in some cases, bad for the app itself which doesn’t utilize native elements and behaviors that ultimately, could create a better user experience particular to that platform.

So here’s the answer to the burning question:

Can you Android-ize an already existing iPhone app? Does one size fit all?

No, not without confusing the user with elements they’re unfamiliar with and possibly missing out on better ways to present a feature using the platform’s native standards.

In regard to user interaction design, there are some big differentiators between the three platforms. Here are some of the big ones:

Android and Blackberry platforms have menus

They both have hard keys on their physical devices that make it possible to bring up a menu and navigate to other options or shortcuts, the iPhone doesn’t. This helps in some circumstances, to hide what would normally be considered clutter. It allows designers to conceal additional features and functionality for when the user is ready to use them. It may make the user experience actually easier by requiring less taps or clicks.

They both have hard keys on their physical devices that make it possible to bring up a menu and navigate to other options or shortcuts, the iPhone doesn’t. This helps in some circumstances, to hide what would normally be considered clutter. It allows designers to conceal additional features and functionality for when the user is ready to use them. It may make the user experience actually easier by requiring less taps or clicks.

Android and Blackberry platforms have a back key

Same as above. This makes it easy to remove controls that would otherwise be necessary to go back.

Blackberry screens come in several different sizes

In my opinion, this is why Blackberry’s App World has a long, long way to go and may ultimately, fizzle out. Designing and developing an app that works on five different screen sizes is a headache. It requires a great deal of production and time from designers and developers and leads to too many compromises. In order to save time and money, the app’s design is required to be generic enough to work with all the various device models. To understand this better, check out Pandora’s Blackberry page.

Blackberry uses a trackball on most of its devices

This is yet another hindrance to Blackberry’s success in the app market. While trackballs work fine for scrolling through a list such as your email’s inbox, it’s cumbersome when it comes to navigating through the tabs of an app, especially if there are two sets, one at the top and one at the bottom. Unless there’s something I don’t know (Blackberry users?), a user must select all the screen’s components (tabs, buttons, fields, hyperlinks) on the way to navigating from one end of the screen to the other. There’s no way to fly from, lets say, the top-left tab to the bottom-right tab like you can do with a mouse or even better, your finger. Everything snaps to a grid and the trackball cursor must follow it. Needless to say, this is extremely cumbersome and requires that screens have few selectable components.

Pop-ups in Android are completely customizable

One nice work-around with Android is that pop-ups are completely customizable. This means in some cases you can use a pop-up interface rather than having to take the user to a new screen. Where would this be helpful? Any kind of detail screen where the user taps an element on the screen to learn more. The pop-up can be customized to have its own background, scrollbar, icons, etc. (caveat: Android pop-ups are not meant to be used like this, so it’s a bit of a hack from what I understand).

iPhone apps don’t use standard web browser form components

What, no radio buttons? No drop-downs? Nope. While web pages displayed on the iPhone do have these options, iPhone app interfaces don’t. Instead, they have switches, slot machine-like pickers and sliding knobs. This is a good thing—they thought about the new touchscreen technology and adapted the UI components to fit it. From a design point of view, this means that you will have to think of how to set up form components differently.

Needless to say, there are also many visual differences between these three platforms. Once you figure it out, Android actually has a pretty nice graphical user interface. Again, there biggest problem is not giving designers and developers enough guidance (i.e., this is what a progress bar looks like, this is what a standard OS button looks like, this is what a pop-up looks like, etc.). In return, their collection of apps appears somewhat clunky and doesn’t have the same cohesiveness that the iPhone’s apps do. This might not be such a big deal except for Android users never know what to expect and the constant use of iPhone-like components in Android apps (such as the ubiquitous shiny buttons) makes Android appear cheap. Android has some exceptional functionality, why not do the same with the UI standards? All it would require on their part, I believe, is a well-written user interface guide.

So, again, how do you design for three different mobile platforms without losing your marbles?

One at a time. Each version of the app will have the same list of key use cases but will require a fresh perspective when it comes down to user interaction and screen layouts. In some cases, like the Blackberry, you can’t squeeze a square peg in a round hole. You have to take it for what it is: a conventional mobile phone UI. Each platform has its own unique challenges and that’s half the fun of being a designer or developer.

Lastly, I’d like to speak directly to Apple, Google, Blackberry and Palm on behalf of all those who seek a better understanding of these interfaces and wish to design and develop a coherent user experience for these platforms. Just as you have given developers the tools to code your apps, you should give designer’s the tools to design your apps. Offer up layered Photoshop, Fireworks and Illustrator files of all your UI components just as this kind person has done for the iPhone and these people and these people. Why make it hard for everybody to put together an accurate representation of your interface? Give us the visual language so that we can, as designers, design useful and intuitive apps that contain the visual standards your users are already accustomed to. To Google’s credit, they do provide templates for creating menu icons, but offer little more for the designer. It would go a long way to not only provide an SDK but also a “software design kit”.