Make the right FAB

Make the right FAB

Floating Action Button, or, in short, FAB, is one of the unique UI element in Material Design for primary/promoted action for a particular screen. Since it is a frequently accessed UI element in a given screen, I think it’s important to make the FAB right in every details. However, there are a number of apps doesn’t have the right FAB as specced in the Material Design Guideline, which also included some of the Google apps (I know!).

Continue reading

An example of really bad mobile app design – Maybank2u


Disclaimer: This post is mainly about the author rant about bad mobile app design from the largest bank in Malaysia, but it is also a great example of don’ts in mobile app design.

It’s September 2014. Material Design was introduced few months ago during Google I/O 2014. The predecessor – Holo Design was introduced late 2011 together with the launch of Ice Cream Sandwich (Android 4.0), which is about 2-3 years ago, and it’s getting matured as time goes. It’s probably not wrong to expect any Android apps published in the year 2014 embraced with all the lessons that we have learnt in Holo Design and craft the best Android experiences for the user.

Except it’s not for Maybank, the largest bank in Malaysia, and one of the world’s top 100 banks.

Last week, they have officially launched their revamped mobile banking app, claiming that it has the best mobile banking experience compared to the previous version. It does seems to have a refreshed design – except it’s probably one of the worst and most unacceptable mobile design that I ever seen. And it’s 2014.

Continue reading

Crafting the Unclouded experience


Unclouded by Christian Göllner, an app that helps to analyse and clean your cloud storage (Dropbox and Google Drive, for now) has just recently out of beta, and I have the honor to work together with Christian on the design for this app. I was really impressed by the app quality when I first received the early build of the app – without hesitation, I told him that I wanted to work together to bring this app to the level of awesomeness. It is super amazing that the app has been featured by Android Police, TechCrunch, CNET, Lifehacker, and xda-developers, and these boosted our confidence about the design and development direction of the app.

In this post, I would love to talk about some design details that we have worked hard to fine tune in order to craft the ‘Unclouded’ experience that we have visioned.

Continue reading

How I would further improve TuneIn Radio app


While this blog post titled ‘How would I further improve TuneIn Radio app’, but I thought I would also like to take this opportunity to touch on the topic about consistency in visual design for mobile apps. No, this isn’t a fight between flat, skeuomorphism, gradient etc. – this is about embracing the consistency of visual design for better aesthetic integrity of a product regardless of the visual styling you opt for.

Visual Consistency is for better aesthetic integrity

One of the graphic design principles that I found here fit the context very well:

While creating rhythms and variations from page to page, one must also remember to maintain an overall aesthetic integrity. The purpose of graphic design is to communicate, not dazzle, and an inconsistent design will result in decreased user effectiveness. This means keeping individual visual and typographic elements simple and clear. It also means applying them uniformly, so that the connotations of a particular type style, or the results of interaction with a particular graphic element, are independent of their context. There should be an overall visual system to the text, carefully considered in the first stages of design, that brings together the elements into a coherent whole.

And of course in Android Design Guideline about branding:

If you take this approach, make sure your (brand) styling is applied to every single icon in your app.

Keep it Consistent

Let’s have a look at the things that I would improve on this app (most of them are about visual consistency):

  • Remove the useless splash/loading screen
  • Need design consistency on Android UI elements (Nav Drawer indicator has inner shadow, overflow icon doesn’t have it, and both of them are in dark colors)
  • Use tabs instead of Nav Drawer. Here’s why
  • Use larger text size in general
  • Make full use of space for interaction rather than using hyperlinked/underlined text
  • Use appropriate (touch-friendly) size for interact-able elements
  • Need design consistency on similar items for maximum familiarity and predictability
  • Show hint if the horizontal list is scrollable
  • Avoid unnecessary paddings
  • Need consistency on font type used in the app
  • Need design consistency on icons (some are flat, some have an outer bevel effect, some have inner shadow)
  • Avoid truncated texts if it’s possible
  • Use blurred background in a proper way
  • Slider that can’t slide? Not needed.
  • Be aware of the bad readability caused by font color choice and background
  • Gradient Now Playing bar? Looks old and just out of place.
  • Use animations to correlate between the full mode and minimize mode of Now Playing
  • Car mode doesn’t have to look THAT bad












What do you think? Do you like the redesigned version of TuneIn?



Unoptimized tablet experience is a missed opportunity


It is first started as a simple Google+ post after I saw the refreshed UI of Bank of America app which probably looks OK on the phone, but terribly on the tablet device, and I thought this topic actually worth a short blog post. Well, let’s first have a look on some screenshots of the refreshed UI of the mentioned app:

Navigation Drawer
Navigation Drawer
Details Screen of an Account
Details Screen of an Account

There are obviously many UI/UX improvements that I can suggest, for example:

  • Misuse of available screen estateNavigation drawer is not done right and taking away too much of the core experience of the app – navigation drawer is meant to be transient. Also everything looks stretched-out and blown-up which make readability and glanceability become really bad.
  • Lack of Pure Android Experience – It’s 100% iOS experience – Tabs at the bottom, right caret, iOS top bar etc. There are certain UI and interactions elements really unique to Android to provide the user the best and pure Android experience, and this shouldn’t be taken lightly if you care about the user.
  • Lack of attention to details – Even for an untrained eye, it’s pretty obvious that the icon and text wasn’t aligned in a proper way – Mind the gap.
  • Terrible tablet experience – Rather than a blown-up version, a multi-pane layout should be already considered if tablet is meant to be supported.

Unoptimized tablet experience is a missed opportunity

We are currently living in a multi-screen world that we are no longer performing daily activities only on the computer, but also on the smartphone, tablet and TV. Of course, this does not apply to every single activity, but most of your digital activities can be done on any devices, and thus, there is always a chance that your user will try to accomplish a task using your app/service with any screen at any time. Unoptimized tablet experience would mean a missed opportunity – for the brand, for the customer experience, and for the customer loyalty.

And with the huge market share by Android tablet, it is probably no-brainer to pour in a little bit more efforts to optimize the tablet experience (unless your app/service does not make sense on the tablet at all) because tablet has penetrated in many users’ live faster than you could imagined.

What’s make a good tablet experience?

Make full use of available screen estate

Gmail in Tablet
Gmail in Tablet

Gmail app is a great example showing that multi-pane layout works really well for tablet, especially for apps that have a list/grid view and a detail view. This will enable the content navigation for the user while still provide the full experience on the content details.

Optimize the content density

Google+ in Tablet
Google+ in Tablet (Optimized Content Density)
Facebook in Tablet
Facebook in Tablet (not-optimized content density)

With the available screen estate, especially the horizontal screen estate in Landscape mode, it is crucial to optimize the content density to show the user more information on screen at one time. Of course, this doesn’t mean that you have to show the information as dense as possible – finding that balanced density is very important (and tricky) – and this optimization must be able to enhance the content consumption experience (the user consume more information with the same amount of effort compared to small screen devices), and if it’s not, it is probably mean that the content density optimization doesn’t work. It is important to design the app with great tablet experience for the user to appreciate the screen estate available on the tablet, not just treating it as an enlarged phone. Compared to the Facebook app, Google+ able to show more information at the same time, fully utilize the available screen estate.

Cares about content consumption quality

Newsstand in Tablet
Newsstand in Tablet

If you look at the screenshots of the Bank of America app, you will find that you will have some difficult time to connect the information on the left and the one on the right, because the readability is not optimized due to the stretched layout, causing the severe disconnection between the information on both sides. In the above screenshot, it is a good example showing why you should not fit the content (especially texts) as much as possible because you would also want to make sure that the readability is great (here, of course, we talk about the optimal line length), so the user can have great experience during the reading (or content consumption).

Tablet experience should not be an afterthought

If you app will be used by tablet users, always design the app with tablet experience in mind (as shown above) and make full use of responsive design. Besides that, Android team has written a nice checklist for tablet app quality, so you definitely need to go through it to ensure that you are providing the best quality and experience for both phone and tablet devices.

I hope this post is able to inspire and motivate Android developers and designers to optimize the tablet experience and it should not be an afterthought in app development. If you have any comment or question, feel free to leave it at the Comments section, and I should be able to respond accordingly.

More high quality tablet app!

Navigation Drawer Done Right


With Google+ on Android just updated with new navigation menu and ditched navigation drawer, this article might not be applicable anymore in the near future for Android Design, though I don’t think navigation drawer will be phased out very soon.

Finally, Gmail on Android has been recently updated with the proper Navigation Drawer interaction pattern (the lower-level edge-swipe drawer access, as well as the Settings/Help/Feedback placement), and I am pretty happy about it because we can finally talk about consistency for this design pattern (I am aware that Google+ and YouTube on Android have yet to change).

I am sure you have (if you always look around for UI/UX articles) come across this article about how navigation drawer reduces half of the user engagements or why or how to avoid hamburger menu – if you are not, I would suggest you to read them – these are some interest reads. Although for the Zeebox case, I couldn’t fully understand the decision to go for navigation drawer – it was pretty obvious that navigation drawer is not needed, and I would probably go for the QuickReturnTabs (in the current Twitter app) to regain some of the screen estate – though it’s appreciable that their A/B testing indicates that obvious helps.

These articles (and I think there are more in the wild) suggest that side menu is a bad design pattern and avoid it at all cost, but I say – in Android Design, you can absolutely use it, but only if it’s really necessary and it’s an informed design decision.

Understand Navigation Drawer in Android

In iOS, particularly iOS7, the side menu does clashed with the navigation element (back button) at the top left, as well as the edge-swipe that will act as back (which is not consistently implemented in all Apple apps if I am not mistaken, correct me if I am wrong), however, this is not the case with Android. The navigation drawer for Android is much more sophisticated where the edge-swipe is reserved for accessing the navigation drawer at any lower-level screens (discoverability could a problem here I know), making the top level navigations slightly easier and more accessible even though you are at the deeper level in the app structure. This potentially eliminates the Platform Navigation Pattern Clash mentioned in Luis Abreu’s post (of course he meant in the iOS7).

Information Architecture (IA) optimization

I do agree with Luis Abreu about Information Architecture optimization when you are tempted to use Navigation Drawer for your app – Navigation Drawer isn’t simply an answer for every navigation need. It is always good to rethink from a high level perspective about the app structure to find out whether the navigation can be made a little bit shallower by removing any unnecessary level/information that doesn’t help exposing the important content to the user – in Android Design Guideline, there is a pretty nicely written recommendations for app structure.

Do it right


However, if it’s really necessary to use the navigation drawer as the top-level navigation pattern after careful consideration, just do it, and do it right. It’s not that I do not encourage variations (which is great for a platform), but for UI elements that involved heavily with interactions, it will be always good to stick with the one that is recommended in the design guideline for consistency, familiarity and predictability. We always want the user to ‘learn once, applied everywhere’, especially from an Operating System point of view – I hate to say this but it’s part of the responsibility of the Android developers and designers to help pushing this established* consistency so the user will have less interaction friction when they are shown with a specific UI element. The faster the user able to operate the app and achieve what they want to do = happy user.

*I know some of the Google apps are still yet to be consistent with the latest changes in navigation drawer, but I am sure they are working on it. Mind you that navigation drawer has come a long way and it takes time to get things right (I wrote about this back in 2012)!

“What’s out of sight, is out of mind.”

In Anthony Rose’s article about Navigation Drawer and a tweet by Luke Wroblewski below shows that when the navigation pattern is less obvious, the user engagements reduced (although I am not sure what’s the parameters in Luke’s chart).

Sure, for some, these statistics seem worrying – but I don’t think we have yet to see the whole picture in these examples. What does the reduced user engagement means? Does it mean they don’t explore the app anymore or it simply means the first screen (home screen) is already sufficient? Does it mean that the user accomplished what they want to do with the app much faster (with lesser distractions) and thus less engagements? I would probably see this as an achievement if my app is meant to help in productivity because it might means that my app helps the user achieve thing faster.

While I fully agree that we should keep “what’s out of sight, is out of mind” as one of the design principle, but it doesn’t mean that we have to show everything as long as we can, because every UI elements play different role during the user interactions and each of them have it’s own unique importance.

So next time when you come across the use of navigation drawer, make sure it is really necessary to do that – and the new Google+ app just show that Navigation Drawer is not really needed sometimes.