Android UI/UX Tips #4

It has been a while since the last Android UI/UX Tips, but I still continue looking for things that can be improved whenever I have some time to find them or actually experiencing them myself.

I am not sure if I can say I am happy with the release of Android 4.2 in terms of UX, especially with the decision to include the Quick Settings panel that isn’t much useful, and a strange bug on the date picker for Contacts app which should be fairly simple to detect if the testing is done thoroughly.

In any case, let’s look at some UI/UX tips that I would like to share.

Tabs should be placed on top

In Android Design Guidelines, it has clearly suggested that tabs should not be placed at the bottom, since it is a very iOS UI element and doesn’t fit in too nicely in Android interaction behavior.

However, looking at the recently released Beta build of Echofon – there you can find the ignorance from the development team.

One of the main justification for placing the tabs at the top is that the user will have hard time to see which tabs he/she is currently in while swiping across the tabs (try it on a phone device). Juhani also written a great article few months back to justify the placement of the tabs should be at the top.

So my advice, try not to ignore the guideline and do not invent new UI element that doesn’t help in enhancing the UX.

Use Simple but Precise Words

Sometimes it is unavoidable for developers/designers to add some words to explain certain things in the app, like instructional guides or options in Settings page. However, it is not hard to find some bad examples in the apps world, either they used long but unclear explanations, or some simple words that simply can’t explain clearly for certain options/features in the app.

One example that I would like to show here is the new Gmail app that comes together with Android 4.2. If you are an early adopter of Gmail app version 4.2, most probably you are aware that it finally has a pinch-to-zoom feature for the email content. However, it is not turned on by default. And what’s really surprising here is that even the option to activate that feature is in the Settings page, many (including myself) have overlooked the existence of this option. Some might blame themselves for the overlook, but really this is actually an UX related issue.

The words that they used to explain the option isn’t something really straight to the point – especially the word ‘auto-fit’, I am not really sure if there is anyone familiar with it. The further explanation might clear the confusion a little bit, but definitely it can be improved. I am sure if it change to Pinch-to-Zoom Content with the explanation Automatically fit the message to the screen and allow zooming, 90% of the people who overlooked this will be able to turn on this feature without having a doubt, and it is also clearer to any new users, I supposed.

Therefore, simple but precise wordings/messages to the user is the key to avoid miscommunication or feature overlooks.

Ensure proper UI presentation

It’s a pity that the stock Email app doesn’t get any updates ever since ICS (at least I am not aware any of them). In Android UI/UX Tips #1, I have questioned on the navigation buttons in the app, and now I have found more things that can be improved during my daily usage.

If you need a borderless button in the middle of UI (in this case the Email app), please make sure that the user should be able to press it anywhere along the entire button area, otherwise if you would like to make it work only on a specific area, remember to use a vertical separator. Gmail app is doing this absolutely right.

 

Ensure Action Hints are working properly

While it doesn’t seems to be a crucial feature, but I would really make sure that the Action Hints are always working correctly, showing the helpful hint to the user about the iconized buttons.

In Email app, when you long press on the navigation button, it actually show the Action Hint toast box without any text in it. This should be avoided – it doesn’t provide any helpful hint to the user and it doesn’t give any good impression on the app quality either.

That’s all for this Android UI/UX Tips! As usual, hit me with comments if you have any.

Advertisements

Android UI/UX Tips #3

In Android UI/UX tips #3, I have looked into some apps with the following UI/UX problems:

  • Hidden Status Bar (UX)
  • Outdated Action Bar and low-res icons (UI/UX)
  • Bad offline handling (UX)
  • Obstructive UI elements (UI/UX)

Hiding Status Bar? Do it Properly!

Some of the app designers/developers didn’t realize that the Status Bar is actually part of the System Bars, therefore if you decided to play around with it to get the maximum screen estate for your app, you have to do it right.

Let’s take RepliGo Reader as the first example. The app is actually pretty good in terms of features and UI, but I didn’t quite like the way it handles the Status Bar. It only allows the user to choose between Always Hide or Always Show option during Reading Mode, which is kind of limited. If they can also include a Show/Hide Together with Other Controls option, then it will be a pretty great user experience, and this should be the default behavior. Look at Google Play Books app, it handles the Status Bar nicely.

Another app that worth mentioning for this issue (which actually bothers me since Jelly Bean) is the stock Gallery app in Jelly Bean. This app has two issues with the Status Bar:

  • In Landscape mode, Status Bar disappeared and there is no way to bring it back.

This is one bad UX example in stock app. Given the importance of the Status Bar in Android device, my suggestion is don’t hide it in any screen mode unless the user is well aware of some method to call it (tap anywhere to show it, for example).

  • In Portrait mode, the black bar of the Status Bar permanently stays on the screen in Viewing Mode (only in Jelly Bean).

I am not too sure if there is anyone noticing this but this is pretty frustrating for me. I have been using Gallery app to view my app mock up in full screen (which I just need to trim off the bottom Navigation Bar), and it doesn’t work anymore because the black bar of the Status Bar is now taking up the Viewing Mode space as well. Thus, if you are going to hide the Status Bar in your app, hide it completely!

Use the new Action Bar and High Resolution Icons

With the release of the awesome ActionBarSherlock library that allows the developer to implement the ICS/JB Action Bar with full compatibility from Android 2.x, personally I am not too sure why there are tons of great apps still decided to stick with the older (and less aesthetic) Action Bar design and/or low resolution icons. Besides making your app feel aged, it doesn’t give any good impression to your user if your app using lower resolution icons – remember, Action Bar is one important UI element in Android Design which is always visible to the user. Some examples below (I am sure you can find more):

So, forget about the old Action Bar and start designing/redesigning/developing Android app using new Android Design!

Properly Handle Offline Situation

It’s true that most of the apps nowadays require internet for their full capability, either to get new information or for syncing purpose, however, we cannot expect our user are always connected to the internet, therefore you have to properly handle the situation when the device goes to offline.

I had this issue with The Verge app which actually crashes when I try to play around with the app offline. Definitely not a user experience that you would like to introduce into your app. Handle it with a simple toast or a warning message regarding the offline status would have solve the issue.

Obstructive UI elements is a no-no

It is so awesome that Android developers have numerous of great libraries for certain UI elements implementation, but once you have used those libraries; you are basically responsible for everything that you decided to show to the user.

One bad example of this is, again, The Verge app, which shows the Pull-to-Refresh indicator and overlapped with certain UI elements in the app (one of the examples shown above). I am not too sure the complexity in technical terms, but I assume it won’t take months to remove it? Publishing your app in such condition will only give bad impression for your app overall quality.

Hope these UI/UX tips help! As usual, don’t hesitate to leave your comment!