As of version 25 of the Design Support Library, the Bottom Navigation View(BNV) is a native component in the Android Framework. There is no need for me to include a foreword to explain a year old component, and this write-up is not so much a guide on how to implement it than it is a discussion (a bit of a rant as well). A discussion that involves both technical and design knowledge. So, let’s get cracking shall we?
Material Design Guidelines
This is the primary reason why I was driven to write this article, well, this and my boss, because I believe we as developers should adhere to the guidelines and standards that is set up by our respective domains.
Guidelines such as code naming conventions, Git workflows, design patterns, UX practices, and even non-development related standards are there for a reason; reproducibility and mutual understanding.
Most software development practices are derived based on the learnings from previous mistakes, and that is no different for the Android Framework.
However, opening up a Google developed app, say, Youtube or G+, and comparing it to the Material Design Guidelines for BNV presents a contradiction to my case. Go on, compare them, I’ll wait.
See the difference?
I was utterly gobsmacked when my client highlighted this to me (sue me, I don’t open Google’s apps that often)
So the obvious question to ask here is why did Google not follow its own Material Design Guidelines?
Google is not very well-known to sticking to its guns in many things, but this violation left me puzzled.
It is explicitly stated in the Guideline that if there are four or five actions, display inactive views as icons only.
Surely, I thought to myself, the Guideline is outdated. Fair, considering that the Guideline was created before the BNV component. Perhaps Google’s Android dev team has foreseen such use case and decided to allow developers to choose their poison, such is the philosophy behind Android.
Shifty Compromise
A hack. This is what it comes down to.
So, to the documentations it is.
Wait, there’s no mention of configuring the BNV’s state in the description, and neither are there any public methods to accomplish that. I half expected a disableAnimationThingyamajig method to be an answer to my woes. Which made me wonder… what even is the name of the state I am trying to disable?
Screw it, StackOverflow it is.
Half an hour into StackOverflow and I was left with my face buried in my palms, chuckling maniacally. A hack. This is what it comes down to.
From my search, this was the only viable solution. There are variations of it around SO, but the general implementation is the same.
I consider this a hack because:
- We are using a restricted API, specifically the mShiftingMode. This means that somebody explicitly hid this away from the public. I did not realise the sin of my code until I looked up what a “RestrictedAPI” could’ve meant. The developer who hid this implementation might’ve decided it’s not ready yet, or that exposing it would produce unpredictable results.
- We are forcing the BNV to do something it’s not designed to do. Referring to line 185, I infer that every individual BNV navigation item view is forcefully “reset” and redrawn to update their UI state. This block of code assumes too much to justify as an acceptable compromise.
Accepting the “solution” just because it received the most karma on SO does not make it a good solution. So, if this is a hack, what alternatives are there? If the Guideline is to be taken as the source of truth, then the native “Shifting” nature of the BNV is the right solution. Problem solved!
Not.
Now comes the UX aspect of this article; conveying intent. Compare Figure 1 and Figure 2 again, which BNV implementation is the least ambiguous? I think Figure 2 wins hands down. Sure, you can probably infer that the second tab in Figure 1 is music related even without the title text, but what about the rest? The BNV implementation in Figure 1 requires the user to tap on each tab to unravel the intent of that tab, information at a glance becomes ambiguous at best.
The BNV implementation in Figure 1 is what’s called an anti-pattern, it slows the user down and does not provide any value in return whatsoever. Why bother with the animation? Why not instead spend that time to allow the text to be dynamic to accommodate more tabs? As you can see, the rabbit hole goes on.
Closing Thoughts
Most times, being an Android developer I find myself between a rock and a hard place. On one hand, I’m trying to stay true to the Guidelines and implement clean, scalable code to the best of my abilities. On the other hand, the very same Guidelines stab me in the back when I try to reach to a sustainable compromise with my clients.
But you see, Google’s app do such and such, why can’t yours?
It is a reasonable question, one that I will concede to in most cases. But this is not one of those cases.
So how is it that Youtube did it? Perhaps they have an internal API that gives them the capability? If yes, why isn’t this exposed to the public? If not, why is Google wrangling with their own code and directly violating the same guidelines they themselves wrote? What is the meaning of life? These questions might never be answered, but somebody needs to ask them before it can even be attempted.
Regardless, we are in 2017, not the Wild West, and this cowboy ain’t wrangling this component no mo’.
