10 User Experience Tips for Successful Android Apps

by Antonio Wells Nov 16, 2009 5:00 AM – 3 Comments

As we know, app sales on the Android platform has not been as strong as iPhone. AndroidTapp.com has summed up a few tips to help Android Developers create better Android Apps from a user experience perspective. Which could induce more organic exposure and/or sales. Here we go…

Allow users the option to kill your app

One of the perks devs receive from the Android OS is it’s own ability to kill your app by handling it’s own multi-tasking. Allowing users the option to kill, quit or log off your app is very convenient.

Save data to SD Card

Most developers save data to the internal memory (which is a known problem for early Android phones with little internal memory resources). Saving to SD card would be preferable when possible, then default to internal memory when no card/full card is detected. Saving small bits of information like settings, configuration or session states on internal memory is fine.

Allow cached data to be deleted

Application Info Comparison

If you’re forced to save data to internal memory, allow the option to clear data in the application settings menu. One of my favorite Android apps is K9 Mail for handling multiple email accounts, yet all data is saved internally and grows as your inboxes grow. The highest I’ve seen it grow was just over 7MB, the only way to reduce the data size was either; sync email with Outlook which reduces the recent number of email on the device or wait until new emails cycle larger older emails out. Which leaves the option of uninstalling, reinstalling, reconfiguring inboxes to reduce data size… (but luckily you can clear the Cache from the app)!

Give users the options for update intervals

Allow Setting Update Interval

Some Android apps and widgets have a set update interval for the app to grab data. Intervals too short (like every minute) keep the app updated frequently, but the downside is the toll on the known-to-be-weak battery life on Android phones and the performance hit due to frequent background processing. Allow users the option to change update intervals in the settings menu, and set the default interval to something more suitable to the user.

Invest in a User Interface/User Experience Designer

DoIt List of Tasks

When you can bring the harmony of stunning yet user friendly user interface design with solid functionality, you’ve created a solid base for your app. Take Apple’s philosophy with setting up iPhone developers for success with their default OS UI… even a developer designed app looks good. Android however doesn’t offer the sexy OS UI as it’s rival, meaning some developers/firms should hire a designer to create this for them. Especially those firms brand conscientious.

Organize your app, don’t over complicate navigation

Tabbed Navigation

Complex or inconsistent navigation gives user the flux. Tabs appear to be the most practical and intuitive navigation structure.

Assume the customer is impatient

Defunct Espressomind.com once wrote “13 Personal Proverbs for Good Android App Design” and one point talked about the impatience of the typical user mobile app user. Assume that users don’t care for waiting on your app in any way. Benchmark your app in the testing life cycle for speed.

Don’t run background processes if not necessary

In our review of PhotoShop.com Mobile, this app exhibited probably the worse case scenario of this at debut. The background processing was meant for continuous upload to PhotoShop.com when using that feature while doing other tasks, but the background processing on this app is very persistent… even after you kill it with task management apps. Poorly controlled background processing apps can attribute to a sluggish phone and fast battery consumption.

Listen to customers and provide updates

We recently wrote ”Google’s Late Release of Android 2.0 Hurting Developers” article to help raise developers awareness regarding getting their apps updated to Android 2.0 to support new Verizon DROID customers (which sold over 100,000 phones in the first week)! Which points out Google’s trend of short SDK releases to developers and how they should expect this, adjust to it and get those Android apps updated ASAP!

You should also listen to your customers complaints in the Android Market as well. Some complaints may even lead you to great feature enhancements that propel your app ahead of your competition.

Factor in your own customer service along with technical support, because Google ain’t providing it

Google’s Android Market Turning Developers into Customer Service Reps?

If you’re selling apps, you should factor in Customer Service which is different from Technical Support into your business model. In our gripe “Google’s Android Market Turning Developers into Customer Service Reps?“, we point out Google’s Android Market lacks the delegation of customer service, yet pushes them back on to developers. Allocate some resources to answering billing questions or “the app didn’t download” issues although that should be Google’s turf. To a customer… they don’t care who’s at fault and gripe in your feedback area in the Market.

In all, these tips can save users headache, make them appreciate your app more and incline them to tell others, which may increase exposure and/or sales organically. Android developers can’t just hope their app sell well relying on the “App Boom” model… (Good Idea + First to the Market = Good Sales). If your app is well rounded including aforementioned model, you build something worth organic potential sales growth. In conclusion, stay tuned to AndroidTapp.com for a new program we’ll launch soon to help Android Developers sell their apps in serious volume!

Tags: Android App, Better Android Apps, Successful Android Apps, User Experience

Categorised in: Apps Blog

3 Comments

By Alvin Brinson on November 16, 2009 at 6:28 am:

One important tip missed:

If you’re a developer on previous platforms (chances are you are) check your monolithic application mindset at the door.

Too many apps on Android are written the same way their desktop cousins are: As a single big, huge application all running under one master “Process” that controls everything.

Under Android, however, applications should be broken up into different activities that operate independently. If you aren’t doing this, you’re writing bad applications.

For instance, the update process should be an activity of its own spawned by an alarm on the OS. Thus, when the update loads, it does its update, and goes away avoiding the persistent background process by using the alarm. Use the OS alarm function to schedule this activity, not having the activity running all the time!

And the benefit of doing so allows you to improve the performance of the app. When the user loads the app, the front-end that loads up should be a user interface activity – nothing else! Too many apps start “loading items” or “checking for updates” when I tap on them, and leave me sitting in frustration for minutes at a time staring at a spinning busy indicator. Why is the update checker/content downloader a part of the user interface?? If you are using Android OS properly, it is NOT a part of the user interface.

Proper app design would mean you use an OS alarm to schedule such processes, and thus the data is ready when the user clicks on the UI. Then the UI would be its own activity, not even TOUCHING the code for separate program functions until the user selects those items. Settings? Its own activity. Subscribe? Own activity. Gallery? You got it – its OWN ACTIVITY.

If you don’t understand this, you should NOT be writing for android, as monolithic programming is going to end in a bloated application that causes nothing but user frustration. Please read up on the concepts of Android programming before inflicting your memory/cpu suckers on us.

Reply
By Paolo Amoroso on November 16, 2009 at 8:51 am:

One more tip to developers from a user. When you update your applications published to the Android Market, please always include somewhere a short list of the major changes with respect to the previous version, even when the updates are just bugfix releases. You may post the list of changes wherever is most convenient to you, such as the relevant Android market application entry, an application help/info dialog, the application web site or a link to the full changelog. It’s amazing how many developers, even of paid applications, forget this.

Users typically get half a dozen updates per day and it is difficult and time consuming to figure what changed and whether new useful features are available. This involves running each updated application and exhaustively wading through menus, commands and options.

Reply
By cookiemomster on December 5, 2009 at 6:30 pm:

I am a Droid owner since the second day of release. I so agree with this article. I want to amend the aforementioned paragraph on customer impatience. Why do so many developers fail to include help files or faq’s for their apps? If I can’t start to accomplish something with your app relatively easily then I am probably not going to go research how to use your app. In the same discussion of patience but included with updating, I read many app reviews the first week I had my phone but so many were not available to Droid users. What were those apps and where did I hear of them? Who knows and who cares.

The final thing, the left out information from the above article is that I just got my Droid. I just walked into my first app market. You have been doing this for awhile. It is all new to me. I don’t know what I want. I can’t decide what I need. I am not ready to spend additional money when I don’t know how things are working. I need a little time. Let me check out your app for a week. Also, don’t charge exorbitant prices. Look at the difference between PC market share and Mac. Mac always had better product but higher prices. I am going with the cheaper one. Apps that are under 5.00 I can freely buy if I choose. I don’t feel the need to justify this to my family. But even at 5.00 I can’t afford to buy a ton of apps. At 1.00 each, I can buy a bunch. Sort of like Red Box compared to BlockBuster.

Reply