Top ten common UX errors in Android apps

The Android developer Relationship team is experimenting with countless apps every day, or apps that are being evaluated by countless developers, and they've summed up 10 of the most common bugs after evaluating so many applications.

The Android developers team is experimenting with countless apps every day or by countless developers asking to evaluate apps. After evaluating so many applications, they summed up some of the most common mistakes and showed them in this episode.

Before I formally introduce these mistakes, I would like to say a little bit. These errors are a very common error, that is, you may encounter these 10 errors with 10 applications, or you may encounter all 10 errors in an application. This situation in the celestial look more serious. So, hope this article can let everybody get rid of stones predicament, direct to avoid some common mistakes.

The top ten user experience "anti-mode", the Android developer contact Team for you to present, each typical error has an interesting small title, Hope everybody See (good) (well-behaved) to open (middle) heart (gun).

　Tenth: You must finish loading these things ... Otherwise!

The load here actually refers to the one in the left, a circle-and-turn dialog box. This dialog box should be avoided, and the dialog box that does not respond to the back action is unreasonable compared to a dialog box.

The solution is also very simple, with embedded loading instructions. Of course, if you can do it in the background to load good data that is even better.

　Nineth: You touch me not to!

The first problem is the touch area that is too small. The Android design specifically emphasizes that all objects that can be touched should be at least 32DP high and ideally 48DP, unless your target user is a baby and other hand-small person.

Another very bad mistake is no touch feedback. Some developers do not want to use standard button controls, but the advantage of a standard button is that it provides a visual effect of touch feedback. For users, touching a button without feedback makes them think your application is slower than it is. For users, the perception of speed is what they can experience, and the real speed of loading and running speed is not so easy to be realized by users. In addition, the illuminated touch feedback can also indicate the actual touch area. A list, for example, when a user presses a list item, the whole line of the item is lit, but there is a 16dp blank on either side, which is equivalent to telling the user that the 16DP of the list item closest to the edge of the screen is not the touch area.

　　Eighth: Design ≠photoshop

First of all, students do not learn the right small picture on the pervert. I know everyone is very good at the variety of effects PS can achieve, but improper/excessive use of these effects will only make your application look outdated or worse-amateur.

When you design your application, be sure to prioritize your attention on the content rather than the high light. The user installed your app not to see the shiny buttons, all of these visual designs should end up being for content services, not decorative.

Also, be sure to ensure consistent visual style within your application. No user would want to see the application of a half holo horse. Call the name and criticize the feedly. This appearance is bright, but the setting is like the application of the Jurassic era. In addition, an application should not have too many buttons/marquee/dialog style, one is enough-call the Android-style control directly is a simple and effective way.

And some developers, for the details of the neglect is really outrageous, such as inconsistent measurement, error spacing, the use of ghost animal color (such as my previous micro-letter redesign☺), bereavement font selection ... These are the details that make users uncomfortable, as developers have no reason to ignore them.

　Seventh: the Jurassic visitors

If your application was made in 2009, then your users will suffer ....

The first thing to mention here is the menu key, or the shame of the button. We now have the Action Bar to replace the Jurassic-era menu keys, don't you? Backward compatibility is not an excuse, because if you set the appropriate parameters, the Overflow button will not appear on the machine with the Entity menu key. Of course, you can also have the Entity menu key Machine Force display Action Overflow to increase its visibility. However, do not let the menu keys only pass through the Entity menu key (three dots to the right of Nav Bar on a machine that has only a virtual key) to exhale.

Although the latest Android API has come to Lv 18, you don't have to set targetsdkversion to 18, as long as it's more than 16. If you set the API to Lv 14 or even lower, your application will force the display of three dots on the Nav Bar, which is no more painful for some devices such as HTC one's users.

Another scenario is to continue with the Android 2.3 or even older visual style. This App sometimes looks pretty holo, but when you press a button or list item, the Android 2.3-style orange visual feedback appears (such as MIUI), or scroll to see a 2.3-style scrollbar, or load it to see the 2.3-style loop and so on. This is definitely not what the user wants. said the load in the circle, Roman Nurik slightly stressed that the holo style of the load ring is actually two cycles at different speeds at the same time rotating, can create a more smooth than the single lap of animation.

　　Sixth: pure blood of the hybrid Android

The principle issue here is: don't violate the "pure Blood Android" protocol.

As with headlines, this chapter says, don't move elements from other platforms to Android. I have mentioned this question many times in my previous articles, and I will not begin to talk about it. A few special notes are also common errors:

Right ARROW: Secondary navigation does not have a horizontal mapping on Android. In other words, secondary navigation and horizontal navigation are different.

Bottom tab bar: For Android, the top is the tab bar position

"Drawing on" visual styles from other platforms: What Android users want is Android apps

　　V: navigation is my brand

Don't try to reinvent the wheel. Navigation in apps already has a mature definition of Android, putting application names in the middle of action Bar, or using IOS-style top bar is a silly behavior. Use Actionbarcompat directly, and action Bar Sherlock is a good choice if you need to implement action bar on earlier versions.

In addition Drawer is used to put the main navigation elements, such as search and settings such as things into the Overflow on the line. In addition, the screen content slide revealing Drawer this way is also not recommended (specifically please refer to the previous article on the Android design Trend--navigation Drawer).

Since this article is about misunderstanding, it is particularly emphasized that it should not be put into the Drawer. First on the top of the homepage to explore shopping and personal data is completely fine. The middle search should be put into action Bar because it is a very common "action" and not a "navigation element". Settings, help, about and feedback are all things that should be put into Action Overflow in addition, advertising what the absolute don't have. There is no need to promote your App in Drawer, and it's OK to put it in the "about". As for "My sister's friend has a website, I promise it's very interesting." Please check it out.

　　Four: self-made non-Android style sharing

First of all, note that the three screenshots provided here are positive examples.

In fact, strong application sharing is always the strength of Android. The Android system also offers a handy sharing feature (Action_send). It is not necessary or desirable for a developer to limit the goal of sharing to a few applications. In addition, self-made, Android-compliant sharing is also a good choice, such as the timely on the right, and the Pocket that doesn't appear in the picture, which lists several more recommended ways of sharing for shared content (articles and apps), while allowing users to click More To choose other applications, so that users are overwhelmed by a long list.

　　Third: Using WebView to imitate native application

If you've been on YouTube, it should be easy to see that the app on the left is the ADiA playlist from YouTube, just adding an Action Bar. And the right side is a good example of a third party ADiA application. It takes a responsive design and a native interface, inherits the comments and topics features of Google +, provides viewing features for each issue of ADiA slides, as well as program reminders, is a great application.

Using WebView to simulate a native application is not a smart choice, because in fact his nature is deceiving the user. If you try to use WebView to present Android's core UI controls, it won't work very well. Moreover, this will also cause the operation efficiency of the lower, in the user is not smooth, slow response.

Instead of packaging a web app as a APK release just to "land on the Android platform," Web apps Let it exist as a web app, and Android welcomes Web Apps. Users can bookmark the Web Apps in the form of the desktop, there is no need to specifically publish a disguised as a local application of the Web App. In fact, the user has more time to use the browser, and the average performance of the browser is increasing, and you will not lose the user because the local application is not published. So you don't have to worry about it at all.

Of course, it does not mean that the use of WebView is completely prohibited. For example, GMail used HTML to render the content of the message and the effect is great, four times before the WebView has been used for image browsing.

　　Second: Weak the first screen interaction

No matter what the application, the importance of the first screen is self-evident. To get to the point of user registration, the use of splash screen is very bad. Users would prefer the application to bring content directly to it, while logging in and registering is best left to do when last resort (except for things like Weibo). In addition, let the user understand your application in the end and then ask for registration, is more reasonable.

The correct approach is to integrate the popular social network login options, and detect whether users have installed their clients, if so, can be directly authenticated through the client login, can greatly reduce the trouble of entering user name and password. In fact, you can do as many things as possible to help users quickly register and log in rather than make them feel irritable. In this regard, the integration of g+ login application experience is excellent, I only need to press the login button, select the account, permission on the line, compared to the domestic application of various types of user name/mailbox/password to be more convenient.

Alternatively, you can use the Show animation/Picture slideshow to tell the user what your application is. This is a good thing to do Next Browser.

　　First: android≠ vertical screen mobile phone

Android devices are thousands, not just vertical-screen phones. Poor flat-panel support or horizontal-screen support can only negatively impact your brand (such as MIUI has no support for horizontal screens).

There are a lot of people who are going to be using a mobile phone, for example, those with a car base/charging base. There are many ways to support the horizontal screen, please choose the most suitable solution. And the point here is to not force users to use only one device in a certain direction.

In addition, the Android tablet's share is increasing, although the line between the phone and the plate is increasingly blurred, but this is not a flat support/optimization interface. Android devices include almost every size from 3″ to 10″, so it's reasonable to use responsive design, which provides more reasonable, multiple-screen support. Carefully consider leaving white, layout and other designs, and don't overlook those tablet users. Just two hours of XML work will allow you to do a lot of things.