Article Contents
Honeycomb, the first Android version designed specifically with tablets in mind, was released way back in February 2011. It was built exclusively for large screens and was never meant to reach phones, but it paved the way for Ice Cream Sandwich, arguably one of the most significant updates to ever hit Android. Taking several cues from Honeycomb, Android 4.0 brought about some of the biggest changes to the OS, not the least of which was the advent of virtual or on-screen navigation buttons.
At the time, the use of virtual buttons on phones polarized opinions: some hated the idea while others were quick to sing its praises. There were good points from either side of the fence, but as a whole (and after the dust settled), the change was mostly welcomed. In fact, Ron Amadeo — one of the more meticulous writers this site has had — actually wrote his very first article for Android Police on why he thought virtual buttons would be great for Android.
Ron's arguments covered both the UI benefits and the hardware benefits of on-screen navigation buttons. There's obviously no reason to assume that his points reflect the motives Google had behind making the switch — but I'd be surprised if they didn't at least come close. Back then, Android fans were excited to see what changes this might bring about. Would we start to see phones with thinner bezels? Would it make it easier to hack Android onto all sorts of smart appliances? How would this improve the overall UI? In many ways, these ideas served as a sort of distillation of all the hopes that were riding on virtual buttons at the time, and which ultimately carried over onto today's opinions.
To see how justified our expectations were, it's worth taking stock of the way things actually panned out and considering whether the supposed benefits of on-screen buttons really hold any water.
The UI perspective
On-screen nav buttons can change orientation with the phone so they are always in the same place.
Hypothetically, this would have the advantage of offering a more flexible UI so that the navigation buttons would always be on the bottom of the screen, regardless of the phone's orientation. This is in contrast to hardware buttons, which are obviously fixed to the same place on a device and therefore cannot adapt to the orientation that a device is being held at. In practice, I'm not sure that this is strictly true, or even if it's desirable at all.
For devices with screens that are roughly under 7 inches across (that's about 95% of Android devices as things currently stand), the nav bar is located on right side of the screen when in landscape mode, so the whole idea that they will always stay in the same place on the screen is already out the window. Still, one could arguably make the point that the nav bar will always be on the bottom of the screen in portrait mode and on the right side of the screen in landscape — and that's definitely true. The issue is that the rest of the UI doesn't always change with the navigation bar, so you can sometimes end up with a hybrid layout that is a lot worse than either approach.
The worst offender here is the Google Camera app (though other camera apps aren't usually any better). For whatever reason, the Google thought it best that the navigation buttons should rotate along with the orientation of the screen, but chose to keep the large shutter button fixed at the bottom of the device instead. At its worst, this means that when the device is turned upside-down, the home button is on the bottom of the device, but the shutter button is on top.
The shutter button just can't make up its mind
"Fair enough," you say, "but this ergonomic nightmare is more of the exception than the rule." That's true: most other apps don't behave as insanely as the Google Camera app does, and this criticism may be more accurately directed at the app's developers than the concept of virtual navigation buttons itself. Even so, there are still plenty of situations where virtual buttons are more of a handicap than a benefit.
Take, for instance, all those apps that only support a single device orientation and kick you into whatever layout it decides is best, irrespective of how the device is being held. For example, say you're using an app in landscape mode while holding your phone with one hand, so that it's rotated 90° clockwise and your right hand is on the top of the device. What happens if you tap the home button?
Tapping the home button moves the nav bar from the left side of the screen to the right side
Assuming rotation isn't enabled in your launcher, the entire navigation bar will be swept away from under your fingers, forcing you to either use both hands or to attempt a strange, single-handed shuffle so that you can reach the navigation buttons once again. The inverse scenario is also a frequent irritation for left-handed people like me: since I tend to use my phone mainly using my left hand, moving the phone into landscape mode means rotating it 90° clockwise while holding it from the bottom, so that the nav bar ends up on the top of the device, opposite to where my hand is.
Again, this isn't exactly a huge problem: most people are now more than used to having to use their phone with both hands for even the simplest of tasks. The problem is that this is precisely the sort of issue that virtual nav buttons were supposed to solve, but instead ended up creating one which didn't exist with hardware buttons.
Having a standard layout for on-screen buttons makes them more consistent, doesn't allow OEMs to mess with the button order, and can even allow for greater customization.
This one is sort of true, though not as much as we could have hoped for. Some OEMs have definitely embraced the flexibility provided by virtual navigation buttons, and even allow users to customize their experience almost entirely. For example, the software on LG's phones supports adding and rearranging up to 5 navigation buttons, including a button to easily pull down the notification shade or another to quickly capture a screenshot and annotate it.
Most manufacturers that use software navigation buttons do stick to the standard button order, but those who don't typically don't offer any customization options, so you're basically stuck with what you get.
On-screen buttons provide greater information by being adaptable to different contexts (e.g. the Back button changing orientation when the keyboard is open). They could also offer a bit of text saying what will happen when you tap it, such as showing "Quit" when Back will close an app or "Inbox" when it will bounce you back to your Gmail inbox.
This is actually similar to how "nav buttons" work on iOS: in certain situations, the status bar at the top of the screen will show the name of the app that was previously open, and tapping the (very) tiny left-facing arrow will bring it up again. On Android, there are a couple of cases where the right side of navigation bar will display extra information, such as for when a legacy app still relies on the use of a physical menu button or for displaying the little button that lets you switch keyboard apps. There are also two other times when on-screen buttons morph or change to provide additional information: when the back button points down instead of left to indicate that pressing it will hide the keyboard, and in Android N when the overview button splits into two rectangles in split-screen mode.
However, aside from those few fringe cases, virtual buttons are not more informative than their hardware counterparts. They do provide a bit more context and information, but not as much as most of us imagined they would have.
The hardware side of things
The hardware arguments basically boil down to three points:
Software buttons allow for much greater hardware flexibility, and make it easier to slap Android on anything that has a touchscreen.
They look cool.
Having on-screen buttons instead of hardware buttons allows OEMs to build devices with smaller bezels, larger screens, and ultimately greater screen-to-body ratios.
Let's break these down, shall we?
At least in theory, there's no question that having virtual buttons makes it much easier to get Android up and running on a multitude of hardware configurations. Like Ron said, all you need is a touchscreen and you're good to go. In practice, however, it's not that clear that virtual buttons really offer any significant advantage.
Android Wear is devoid of any virtual (or physical) navigation buttons, since the minuscule screen size of the devices it runs on requires an entirely different UI paradigm. Unofficial products and hacks don't make much use of virtual navigation buttons either: the best smart mirror we've seen doesn't even use a touchscreen at all. The only place where software buttons have arguably made it easier to deploy Android on a hardware setup is with Android Auto — but even that's a bit of a tossup.
For starters, out of the five navigation buttons in the Android Auto interface, only one of them exists in Android's traditional UI: the home button. The other four buttons are little more than glorified shortcuts to apps like Maps and the Dialer, and don't really affect the navigation pattern of Android Auto in any real way. On top of that — and this is more of a personal opinion — I'm not at all convinced that virtual buttons are the way to go with car dashboards. Call me old-fashioned, but I think there are some situations where a physical knob or a pressable button still beat a flat panel of glass, and trying to open up the Maps app while keeping your eyes on the road is probably one of them.
The fact is that getting Android on anything other than a phone, tablet, or possibly even a laptop requires adjusting the UI to such an extent that it's hard to argue that using virtual buttons on a phone is making it any easier to port Android to other kinds of hardware.
Secondly, there's the question of being cool or not. This is a matter of opinion and preference, but I mostly agree with Ron's assessment that virtual buttons look good. Samsung even unveiled a Tony Stark phone at CES last year, but you can obviously only buy one if you're a member of the Avengers.
Image credit: IGN
The final hardware argument for virtual navigation buttons is that they supposedly allow getting bigger screens onto smaller devices, which would result in smaller bezels and higher screen-to-body ratios. The idea is that the space that would have been taken up by physical buttons can now be used to extend the screen towards the bottom edge of the device, or instead to slim down the chin while maintaining the same screen size. The logic is sound in theory — in practice, however, it turns out to be nothing more than a pipe dream.
Smaller bezels? Nope.
Even if you were convinced that virtual navigation buttons led to smaller bezels, you'd be hard pressed to find an example of a phone with a noticeably thin bottom bezel due to having virtual buttons instead of physical ones. That's not to say they don't exist, but they're certainly not the norm.
Take the Nexus 6P and the Nexus 5X, for example. They both have about the same bottom bezel size, measuring around 16.0 and 16.2 millimeters, respectively. But compare this to the 17.2 millimeters you'll find on an iPhone 6S (which sports a huge home button on the bottom of the device) and suddenly it's not clear where all that saved space went.
The bottom bezel on a Nexus 5X is only about 1 millimeter shorter than the one of an iPhone 6s
One of the most touted advantages of on-screen buttons is that they provide the best of both worlds: the navigation buttons are present when they're needed, but they can hide away when they're not (such as when watching a video) — freeing up valuable screen space. The assumption here is that on-screen buttons use up the space that would have otherwise been used for hardware buttons, so that in the worst case (i.e. when the on-screen buttons are visible), the amount of usable screen space is the same. In reality, what most often happens is that instead of increasing the screen height (or decreasing the bezel width), on-screen buttons take up what was previously free screen real estate, so that in the best case (when the nav buttons are hidden), you've got same available area.
You could argue that in this example, part of the width of the bottom bezel is taken up by the front-facing speaker that's present on either Nexus, or that I'm just cherry-picking a particularly thick-bezeled phone to try to prove my point — after all, the previous generation's Nexus 6 had an impressively slender chin. We could quickly get into a back-and-forth citing of anecdotal examples and counterexamples that wouldn't lead us anywhere, so let's instead try to gather some real data and make more conclusive comparisons.
Using data from PhoneArena, I compiled a list of over 50 smartphones that were released until the end of 2015 and that spanned multiple operating systems and form factors. The selection methodology was arguably the most hand-wavey part of the process, but care was taken to give special relevance to flagship models and popular phones, as well as to gather a balanced number of devices both with and without software buttons. Using 2x scaled images, I measured the width of the bottom bezel of each device, as well as the height of the nav bar for devices with virtual buttons, to an accuracy of around half a millimeter or less. The collected data is shown in the table below.
| Phone | Bottom Bezel Size | Navbar Size | Min bezel | Max bezel | Bottom Speaker |
|---|---|---|---|---|---|
| Apple iPhone 4S | 201 | 0 | 201 | 201 | |
| Apple iPhone 5 | 173 | 0 | 173 | 173 | |
| Apple iPhone 5S | 176 | 0 | 176 | 176 | |
| Apple iPhone 6 | 169 | 0 | 169 | 169 | |
| Apple iPhone 6 Plus | 194 | 0 | 194 | 194 | |
| Apple iPhone 6S | 172 | 0 | 172 | 172 | |
| Nokia Lumia 920 | 220 | 0 | 220 | 220 | |
| Nokia Luima 930 | 163 | 0 | 163 | 163 | |
| Nokia Lumia 1020 | 203 | 0 | 203 | 203 | |
| Google Nexus S | 179 | 0 | 179 | 179 | |
| HTC Droid DNA | 136 | 0 | 136 | 136 | |
| HTC One | 192 | 0 | 192 | 192 | ✔ |
| HTC One S | 171 | 0 | 171 | 171 | |
| HTC One X AT&T | 175 | 0 | 175 | 175 | |
| LG Optimus 4X HD | 134 | 0 | 134 | 134 | |
| OnePlus 2 | 151 | 0 | 151 | 151 | |
| Oppo Find 7 | 177 | 0 | 177 | 177 | |
| Oppo R7 | 162 | 0 | 162 | 162 | |
| Samsung Galaxy Note 3 | 120 | 0 | 120 | 120 | |
| Samsung Galaxy Note 4 | 132 | 0 | 132 | 132 | |
| Samsung Galaxy Note 5 | 132 | 0 | 132 | 132 | |
| Samsung Galaxy Note II | 129 | 0 | 129 | 129 | |
| Samsung Galaxy Note LTE | 157 | 0 | 157 | 157 | |
| Samsung Galaxy S III | 176 | 0 | 176 | 176 | |
| Samsung Galaxy S4 | 125 | 0 | 125 | 125 | |
| Samsung Galaxy S5 | 139 | 0 | 139 | 139 | |
| Samsung Galaxy S6 | 151 | 0 | 151 | 151 | |
| Samsung Galaxy S6 Edge+ | 141 | 0 | 141 | 141 | |
| Sony Xperia S | 201 | 0 | 201 | 201 | |
| Xiaomi Mi 4 | 147 | 0 | 147 | 147 | |
| Xiaomi Mi 4C | 138 | 0 | 138 | 138 | |
| Google Galaxy Nexus | 141 | 75 | 141 | 216 | |
| Google Nexus 4 | 154 | 78 | 154 | 232 | |
| Google Nexus 5 | 154 | 74 | 154 | 228 | |
| Google Nexus 5X | 162 | 67 | 162 | 229 | ✔ |
| Google Nexus 6 | 114 | 87 | 114 | 201 | ✔ |
| Google Nexus 6P | 160 | 64 | 160 | 224 | ✔ |
| HTC One M8 | 201 | 79 | 201 | 280 | ✔ |
| HTC One M9 | 184 | 87 | 184 | 271 | ✔ |
| Huawei P8 | 120 | 108 | 120 | 228 | |
| LG G3 | 138 | 67 | 138 | 205 | |
| LG Volt 2 | 150 | 81 | 150 | 231 | |
| Motorola Droid RAZR HD | 154 | 80 | 154 | 234 | |
| Motorola Moto E (2014) | 169 | 67 | 169 | 236 | ✔ |
| Motorola Moto E (2015) | 124 | 74 | 124 | 198 | |
| Motorola Moto G (2014) | 172 | 73 | 172 | 245 | |
| Motorola Moto G (2015) | 140 | 85 | 140 | 225 | ✔ |
| Motorola Moto X | 100 | 78 | 100 | 178 | |
| Motorola Moto X Play | 130 | 89 | 130 | 219 | ✔ |
| Motorola Moto X Style | 136 | 93 | 136 | 229 | ✔ |
| Sony Xperia Z | 148 | 81 | 148 | 229 | ✔ |
| Sony Xperia Z1 | 170 | 74 | 170 | 244 | |
| Sony Xperia Z2 | 159 | 80 | 159 | 239 | ✔ |
| Sony Xperia Z3+ | 154 | 83 | 154 | 237 | ✔ |
| Sony Xperia Z5 | 156 | 86 | 156 | 242 | ✔ |
| Sony Xperia Z5 Premium | 166 | 105 | 166 | 271 | ✔ |
Bezel sizes were measured using 200% zoomed images of devices obtained from PhoneArena and should be correct to within half a millimeter
No one likes combing through a boring list of hundreds of data points, so why not try organizing the information into a colorful graph instead?
Comparison of bezel sizes on numerous different devices
At a quick glance, it's clear that physical bezels are not much smaller for phones with software buttons. In fact, as soon as you factor in the space taken up by the navigation bar (the 'virtual bezel,' if you will), almost all those phones end up having a larger physical plus virtual bezel than even the widest bezel on a hardware-buttoned phone. Among phones with software buttons, HTC phones are probably the worst offenders: with so many bottom bars, they almost look like an inverted Internet Explorer window from the early 2000's.
Doing the math, we find that the median bezel size for Android phones without navigation bars is 14.9mm, while the median for phones with navigation bars is actually more, at 15.4mm. Even splitting those up between phones with and without a bottom front-facing speaker gives a median of 15.8mm for the former and 15.0mm for the latter: if anything, phones with software buttons seem to have larger bezels than phones without. (Medians are arguably the most relevant statistic in this situation, but if averages are used instead, the values obtained are 15.3mm, 15.0mm, 15.6mm, and 14.3mm, respectively. According to these numbers, software buttons shave off a single millimeter from the bottom bezel, at best.)
| Median (mm) | Average (mm) | |
|---|---|---|
| Physical bezel for Android phones w/ hardware buttons | 14.9 | 15.3 |
| Physical bezel for Android phones w/ software buttons | 15.4 | 15.0 |
| Physical+virtual bezel for Android phones w/ software buttons | 22.9 | 23.1 |
| Physical bezel for Android phones w/ software buttons w/o bottom front-facing speaker | 15.0 | 14.3 |
| Physical bezel for Android phones w/ software buttons w/ bottom front-facing speaker | 15.8 | 15.6 |
In the end, there doesn't appear to be any evidence which suggests that virtual navigation buttons will make a phone's bezel any thinner. Tall bezels can't be chalked up to front-facing speakers either: on average, putting a bottom front-facing speaker on a phone only adds about a millimeter in bezel height.
The Sony Xperia Z5 is proof that a bottom front-facing speaker doesn't need to take up too much space
This conclusion is undeniably odd: it stands to reason that if phones don't need to account for the added space required by hardware buttons, their bezels should obviously be smaller. So why is this not the case?
I'm no engineer, and I certainly don't have any experience in building smartphones, but one plausible explanation might that the bottom bezel on a phone simply cannot be made any smaller than a certain limit before you start running into some serious manufacturing problems. Something similar happens with smartwatches: Motorola has previously stated that the 'flat tire' on the Moto 360 is there because of the space required to accommodate the display drivers. And even phones that are touted as "borderless" like the Sharp Aquos Crystal still sport a pretty sizable bottom bezel. Perhaps it's the display drivers, or maybe it's the USB port or headphone jack, but it feels like there's some barrier stopping us from reaching a bezel substantially under 10mm tall.
The "borderless" Sharp Aquos Crystal, with 75% fewer bezels
So why are most Android users such fans of software buttons then? There are a few very valid reasons why someone would prefer software buttons over hardware buttons, but wanting smaller bezels is clearly not one of them. And if phones will always require a thickish bezel anyway, why go to all the trouble of removing physical buttons if all we're going to achieve is reducing usable screen space?
Whatever the case, it's clear there are advantages and disadvantages to both on-screen and hardware navigation buttons, and that it wouldn't hurt to have some more debate on the matter. It's certainly not true that Google is some perfect, infallible company, and just because it decides to do something a certain way doesn't mean it's necessarily the best one.
Put the internet to work for you.
No comments:
Post a Comment