How to Ask Users to Rate Your App?

The way Google's Android Market (or any other app store) arranges apps in the top listing is not well known outside the staff. It is a good thing too. Knowing the exact algorithms would allow dishonest manipulation of the system. Regardless, we all want our own apps to be up high in the listing for them to reach as many users as possible. We cannot affect the algorithm and we should not try to game the system. The best thing we can do is to try to get our user to rate our apps. Positive ratings is definitely a factor when the system orders the apps in the listing.

Don't Be an As#@(&$

There have been few disgracious attempts by dishonest and usually malicious software vendors to force users to rate their apps by claiming that the app remains locked until the user rates it for 5 stars (technically this isn't even possible). Fortunately, these apps have been swiftly removedly from the market by Google. 

But what can we do to encourage users to rate our apps without going to extremes and dishonest behavior like the one mentioned above?

Users Almost Never Rate Apps

Getting apps rated is important and users don't do it that often. There's a good reason why only very few users ever rate an app. Rating is done in the Market Place app (or on the website). Both of these are used for installing apps and aren't very useful after that. People very rarely go back to the Market Place just to rate an app.

Facebook app, for example, has between 100.000.000 and 500.000.000 downloads but only little bit more than 2.600.000 ratings. Less than 2% of all Facebook app users have rated the app. 

The situation is even worse than it sounds. When are we most likely to give feedback about things? It is when they fail. Let's face it. We like to complain when things go wrong. While I don't think there's anything wrong about raising concerns when things aren't working it can distort the public perception of app quality if a small minority of people who encounter problems leave feedback.

What Needs to Happen in TV industry Before We Start Caring

This post might seem at first that this should live some where else than in Android UI Design Patterns blog. I will not be talking about Android smartphone user interfaces (well at least not that much) and I will not be talking about design patterns for Android phone apps. I will, however, be talking about Android and user interface. This post is about my thoughts and personal views about smart TV industry and especially GoogleTV and what I think needs to happen before the next living room revolution truly gets started.

User Interface Problem

By far the largest problem standing between us and mass smart TV adoption is the user interface. All current TVs are just few short evolutionary steps from the TVs of 1960s. The lack of progress is actually very surprising. TV has been big business for a long time. For decades basically every home has had one. 

Thinking back for the last 70 years where are the revolutionary innovations? While of course the technology that is in TVs has advanced tremendously true revolutionary ideas are missing. 3D TV? Digital TV? HD TV? No, that is innovation and progress but not revolution. People really don't care about 3D!

Poll on Slashdot, http://slashdot.org/poll/2323/when-it-comes-to-3d-tv 

Bezel Swipe, a Solution to Pan and Swipe Confusion?

Release of Google Chrome beta for Android was an event that many of us have been waiting for a long time. The new browser is very good even in this early beta phase. 

Google didn't choose to follow an easy way simply replacing the rendering engine in the stock Android browser but did instead rethink mobile browsing user experience. Chrome for Android has a lot of small subtle animations and details that might or might not be gimmicky. Some of them are very useful and some of them might end up being not useful. My tip of the hat to Google's team for trying these things. Time will tell which ones they should let in and which ones they should take out.

Bezel Swipe, Goodbye Pan vs. Swipe Problem

The new browser also introduced a gesture that is not much used on Android but has been utilised on other platforms even in very central tasks like multi tasking etc. It is the bezel swipe. Bezel swipe is a swipe gesture that starts outside the phone UI ie. on the phone's bezel.

A browser is a superb example of a gesture confusion problem I wrote about couple of months ago. In short the problem is that it is difficult to differentiate between user's intention to swipe and to pan the UI viewport.

On a browser user can zoom into a web page which makes the page too big for the screen. User will then move around by dragging with a finger. This is all good and well but what if we want to provide a gesture to move between tabs? A swipe won't do because of the above problem. Having to pan to the edge before changing the tab the way you move between zoomed pictures in the gallery would be awkward.

In the new Chrome browser user can move between tabs using the bezel swipe gesture. While it is not yet perfect (getting the app to recognize the gesture isn't always bullet proof) it is very usable. Once Google engineers tweak the technical gesture recognition algorithms to perfection I believe that this will be very good way to solve the gesture mixup problem. 

New Gestures Always Come with Problems
Introducing new gestures always has the problem of gesture discoverability. Panning and even swiping can be discovered by accident if they're implemented correctly. But what are the chances of users discovering the bezel swipe? For now every app using this gesture must point it out to their users explicitly. But maybe it becomes a common place on Android platform and users start to expect it. We will see.

The Best Default Setting is not to Have a Setting

It is easy to think that letting users change all aspects of an app UI makes the UI better. We've all heard the "if they don't like it they can change it" argument. It is also very easy to come up with theoretical scenarios where users would actually want to change any one aspects of the UI. 

Maybe some users don't want to star emails on gmail. Why doesn't Google let user to hide them? That would save valuable screen real-estate. 

Making something user configurable is not a design "get out of jail free card"!

The reason Google is not letting us remove the star is same reason that everyone should always keep in mind when building apps. Apps can't serve everyone and every use case. It is impossible and apps that try are doomed to suffer from massive usability problems. Apps should be designed to serve their target user group and serve them well. Apps should provide easy access for function that those users need to achieve their goals. 

Don't try to target everyone. Select your core user groups and serve them well.

There are three very concrete problems that come up if app settings are not well thought out.

1. Apps do have settings that users need to have access to. Too many settings will make it more difficult to find the ones that user actually need.
2. It the app settings are later rearranged and rethought it is guaranteed to cause at least couple of one star reviews in the market as at least few people have started to rely on strange usage patterns and suddenly that option is removed. It is better to get them right from the start.
3. Too configurable app will make it nearly impossible to create a consistent user experience. It is better to make your app's UI support your selected user goals than require users to figure out how they can set it up for their needs. 

Should your user have to worry about this setting?

When thinking about app setting the question to ask is: "is this something my users should care about?". There are things that you must let users to set. Users should, for example, always be in control of your app's data usage. If your app is data use heavy you must let them go to wifi-only mode. 

Then there are things that users should never have to care about. User interface should be configurable only in very rare cases. Do you think users should ever care about if buttons are part of a scroll pane or outside it?

Good defaults, best defaults, no settings

Every single setting must have a good default. A good default is something that most users would set it to if they had to choose. A best default is something that users wouldn't even think about. A good default is no excuse for including a setting that shouldn't be there though. Not having a meaningless setting is always better than having one with a good default.

Conclusion

When you're facing a tough interface design problem don't try to get the easy way out by pushing the decision making on users. We are the professionals, we are capable making good UIs. We should be making them.

A Quick Look to Two New Apps

Android market app quality is definitely on the rise despite of couple of disasters. I wanted to take a quick look at two new apps that I'm happy to welcome to the Android Market.


Vimeo

Market link

Vimeo's new app is visually very pleasing. While the visual style could easily fit to iOS it is not actually a copy of their existing design but a new one. There is no doubt that the designers behind this app are very familiar with iOS and likely not yet experienced with Android look and feel. 

The app has few problems though. Firstly, maybe most notably, it doesn't support landscape mode on any other screen than on video playback (which in turn doesn't support portrait). I have no doubt that this will be fixed soon.

All in all this app looks and feels very nice. Good job Vimeo.

Official Android UI Design Guidelines Announced

Google has just announced Android Design guidelines. This is a huge step forwards for the platform! I urge everyone to head to the site at: developer.android.com/design

I think this is going affect my site too. There's no longer need to explain the patterns that Google covers but let's see where we are heading. One thing is sure though: Android as a platform has much brighter future now!

Hands on Open Source Android UI Libraries

In a previous post I listed some free UI libraries. In this one I'll take a look at example applications.

There's no better way to experiment how a UI library works than trying it hands on. Many UI library projects provide example apps that are great for exactly that. These apps will give you a good understanding about functionality in real life on real devices. If you're a dev you can present these examples to your designers and let them see what kind of functionality and interaction is available out of the box.

What makes it even better is that source code for these apps is available. If you need any of this functionality simply download the source and use it as an example implementation.


ActionBarSherlock Demos

http://actionbarsherlock.com/
Market link
Source code

ActionBarSherlock is one of the most useful libraries around. The demo app has tons of examples of different functionality including action bar navigation, fragments, loaders and even service broadcasters.