Did you ever enter a wrong password and got an AlertDialog telling you that you entered something wrong? You probably did and you probably also noticed that this alert dialog most likely takes one more click to continue, a click that could be saved. One way to avoid the AlertDialog are Toasts. Here are two nice but rarely used other ways to tell your users that they should enter something different.
Setup
Let’s assume we have an EditText which we use in our UI.
EditText mEditText ;
//...
mEditText = (EditText ) findViewById(R.id.myEditText );
Furthermore we have a method showError() which we call when the EditText contains invalid data.
1 Shake
A nice way to show the user that, for example, an entered password was incorrect is to shake the EditText. Please note that I took this code from the official ApiDemos and modified it slightly.
First, we have to define our shake animation. Go to your res folder, create the subfolder anim and place a file shake.xml in it. In this file, create a translation like this:
< translate xmlns:android="http://schemas.android.com/apk/res/android" android:fromXDelta="0%" android:toXDelta="5%" android:duration="1000" android:interpolator="@anim/cycle_7" />
TranslateAnimations let us move views ond the x or y axis of our screen. Since we want to shake it from left to right, we only apply the translation on the x axis. We move it from zero percent of the view’s width to five percent of the view’s width and let the translation last one second (1000 ms). Furthermore, we use the interpolator cylce_7 wich is placed in anim/cycle_7.xml and looks like the following:
< cycleInterpolator xmlns:android="http://schemas.android.com/apk/res/android" android:cycles="7" />
It’s a simple CycleInterpolator. This kind of interpolators express the number of repetitions an animation should do. In our case, we repeat the animation seven times.
Now we only need to apply our shake animation to our EditText every time something incorrect is entered. We can do it like this:
private void showError() {
Animation shake = AnimationUtils.loadAnimation(this, R.anim.shake);
mEditText.startAnimation(shake);
}
That’s it. Super easy, super smooth integration into the UI.
2 SetError
This is my personal favourite. It is the setError()-method which comes out of the box with the EditText view. When calling this method, the right hand compount drawable of the will be set to the error icon. When the EditText also has focus, the text you gave to setError() will be shown in a popup. If you don’t like the default error icon, you can also use setError(CharSequence error, Drawable icon) to set your own icon. The routine to show errors can then look like this:
private void showError() {
mEditText.setError("Password and username didn't match");
}
Which will result in errors shown like this:
setError() on ICS
Which looks good, catches the user’s attention and doesn’t need any extra clicks to disappear.
Conclusion
Showing errors without interrupting the user flow can be accomplished easily on the Android plattform. For even more attention by the user, the two methods mentioned can also be combined.
Please feel free to share your methods of showing error messages in the comments.
Reiti (12)
Bearded Robot Apps (9)
AKapps (7)
Paweł Białecki (7)
App Store Optimization (ASO) (4/5): Ratings & Installs or: The Google Play Store Search Algorithm
Another part on App Store Optimization. Finally. By the way, if you are from Germany: There is an article on App Store Optimization in the current Android 360. Go and get it (if you want)!
If you are new to this series, I recommend starting from the first article on App Store Optimization. If you don’t want to read that much, this article can still give you valuable information on its own.
Parts of this series on App Store Optimization are:
1. Keywords
2. Description
3. Icons
4. Graphics
5. Videos
6. Ratings
7. Installs
8. Users
While the last articles covered Icons, Videos and Graphics, we will go more into the search algorithm of the Play Store (I still need to get used to this name), an area that probably fits most developers better. Because this article will cover big parts of how the the Play Store search algorithm (most likely) works, there will be a summarizing Play Store algorithm-part at the end.
6. Ratings
When it comes to two equal apps, the app with a better rating will receive a better ranking. When your app does not have any ratings yet, it will internally get a composite score representing the quality of the apps you published before. This means: Ratings are important. But how to get lots of positive ratings? Well, there are several methods, one of them is to buy them via certain dubious websites (I ‘ve never tried that), another way is to simply ask your users for ratings. This step is actually pretty simple but it can and most likely will improve your ratings a lot, provided that you are making it right:
7. Installs
Installs are important. They are important for you, because many users equals many dollars. But they also are important for the Android Market Search Algorithm. To be more precise: The ratio of active installs to total installs, respectively the refund rate. This will have special weight when your app is published the first time and there are not enough comments to give your app a ranking and no other apps to give your app a composite score.
Since gaining installs and keeping active installs is very important, it’s important to have a well designed and tested app. Boosting user numbers by force can be a very expensive task, that’s why it’s even more important not to lose existing users. To increase the number of downloads of an app, the well known classic methods like writing blogs, creating viral content, paying for ad space or ASO can be applied.
The the Google Play Store Search Algorithm
The search algorithm of Google’s website is known to be a black box of which nobody except Google knows how it works exactly. Guess what: With the Play Store search algorithm, it’s exactly the same. Still, by try and error and a lot of observation, patterns can be recognized. Here’s what the Play Store search algorithm roughly looks like:
Temporary relevance here means the acceptance of the users over a small time period, or in other words the download rates in the last days and weeks. As you can see there is a little ‘black magic’ involved, this is a synonym for uncertain influences like the +1-button, the percentage of solved known bugs with every new update, the relevance of keywords used in the recent changes-description and all the other small and uncertain things.
After various observations, the following rough order can be assumed:
z, representing the weight of various factors, is ignored.
Now, when optimizing your app for the Play Store, you can try to improve your app’s environment based on this order, meaning for example: “Let’s put our main effort into a solid UX, a non-annoying dialog with a high conversion rate asking users to rate us high and a good description.”
Conclusion
You maybe noticed that the Play Store search algorithm changed a lot in the last 18 months. ASO is very dynamic. New changes need to be observed and classified as soon as possible, so it always stays exciting.
I’m open to your suggestion, criticism and questions. Please leave them in the comments.