Design of eight big Android turtle

From the day Android was born, this cute little robot, by virtue of the power of open source, obstinately pushed iOS into the market share of the first position. Although the figures are dominant, iOS is always the mobile platform for the best experience in the public mind.

Admittedly, iOS successfully will be the interface to achieve the results of the simplification, the extreme of the mobile phone hardware to reduce the key to one, so that users can operate the range of items, control in a very small space, effectively reducing the user's learning costs. But since the three-point Nowitzki can still be defined as Duncan as the world's best power forward, why can't Android be defined as the world's best mobile platform system?

Although Android has a variety of hardware key design, in the scope of operation, he is not as easy to control iOS, such as he can be in different interfaces with different menu options to operate, such as an application can run multiple processes and multiple services. However, if you can make good use of him, Android can also provide another excellent experience.

Azi wrote an article called "rather than blindly plagiarism, study thoroughly," said the lack of domestic research on Android, leading to domestic Android applications overall quality is not high. Designers on Android have massively copied the UI elements and design methods on other platforms, eventually leading Android to become a big collection of fake black holes in the user experience. Some of the products we are familiar with.

What is collected here is some of the design methods for the lack of deep research on Android, copying other platform UI elements, or the rape user of a turtle, which is not intended to be blamed, but rather to alert everyone. After all, Shanzhai is something we don't want to do.

There are two kinds of returns in the mobile interface: Return to the previous interface, and return to the previous level of the interface. Android applications, the interface does not appear to return the button, but unified through the hardware back key to complete. So anyway, any return button on the Android interface (including, of course, the return button in the upper-left corner of the iOS) is incorrect and unreasonable.

Of course, there are exceptions, such as in a Setup wizard (Wizard).

In the Android system, the notification bar contains two types of information, ongoing and notifications (some also include the shortcut function switch and the program running list ROM is not covered in this discussion). The difference is that notifications is a notification of new information about various applications, such as new text messages, new messages, etc. He can be purged directly, and ongoing represents some of the programs or functions that are currently running and cannot be purged directly.

However, we should be aware that the ongoing should show that the user must understand, and may give users the impact of the use of mobile phone programs and functions, such as playing music, are talking, uploading and downloading. If your application either exits or runs, it has no effect on the user. It is not necessary to inform the user by the way of the resident Notification column, and give the system the process of managing your application.

First we have to understand the stack mechanism of the Android interface, as shown in the picture, where the user's every action activity is saved, and when the back key is used, the system automatically kills the previous activity.

But if it is already in the root interface of the application, using the back key, all of the application's processes are automatically suspended, except for background services. It does not consume CPU resources, but it takes up some memory. Android is similar to Java, the system has a rule to reclaim the memory, the memory scheduler has a threshold, only below this value system will be from a list, from the back to completely shut down the application process. The advantage of this design is that he can make it easier for users to maximize speed when multitasking, because the process is only suspended.

From the point of view of system design, exit needs to be confirmed or even said to be a rogue behavior. And from the point of view of preventing users from Misoperation, this is also a fallacy. Because when you press the back key, the process is suspended, the user does not have the risk of loss of information, even if it is misoperation, according to the Android stack mechanism, users can easily restore the application. You must have seen iOS press the home button, and give you a confirmation exit box?

I have a deep understanding of why developers do this: Apps in Android are pushed by harsh, and using harsh is based on the fact that the phone is tied to a Google account. The crux of the problem is that some manufacturers ' Android phones don't require users to bind to Google accounts, and they even launch app stores to get a piece.

This is hard for the Android application developers, in order to enable different users to get updated information immediately, they have to add in their own application to check the update function, and then, there is a check update settings.

But ask the developers to think, do you really need to give users this setting? Is your application really likely to be updated daily? Maybe you just have to set a default weekly check update is good.

Sharing is a feature of Android, with only two client support, users can share information in any two local clients, such as saving Weibo to a local Evernote application, and selecting a picture in the gallery to send to a friend via WhatsApp.

The Android sharing feature, which can be arbitrarily local to two clients, can be more efficient in meeting the user's different task processes. such as photo sharing, Android can use camera 360 to set up a variety of filters, directly from any local microblogging client sent to Weibo. Take photos first, then share, also meet the user's operating habits.

Compared to iOS is more cumbersome, or developers trouble to the filter function to the microblogging client, or the user to the trouble of first photo set filter to save to the gallery, and then in the Hair Micro-blog interface from the gallery to select.

The sharing mechanism of Android can effectively avoid the client function bloat, help the developer to save the workload, and also meet the user's various usage scenarios. The real implementation, let an application only solve the user a problem concept, which has to say is the iOS joke.

Some Android phones have input devices such as trackball, which allows the user to scroll the trackball to a control on the interface. This can be effective in helping some touch-impaired users. More importantly, with the release of Android@home, the Android system will likely appear on appliances such as refrigerators, washing machines, and in the form of five-D navigation keys, which makes the focus state extra important.

More predictably, Android has not yet provided a barrier-free solution like the Voice over iOS, assuming that once provided, the trackball can bring a better mobile device experience to more blind users.

7. Large cache of pictures

Android does not completely remove the concept of files, as iOS does, so if your application does not handle cached files like pictures, the images are heavily stacked in the gallery of the system, slowing down significantly. For this problem, simply change the cached picture to gallery unrecognized type.

8. No move to SDcard

If your application size exceeds 5M, if you do not provide move to sdcard function is really sorry, because after all, there are a large number of users only 250M below the fuselage memory space. Of course, Google's map application is still hogging the size of the 12M of the fuselage memory.

Anyway, Android is an excellent mobile phone platform and I love it as much as I love iOS. I also always believe that Android's application can still be very good, even if its development costs are too great.

Recording: http://www.userkon.com/tolyer/eight_bad_design_in_androi.html