The beginning of the trend
Up until late 2011, hardware buttons were the widely-accepted norm for buttons on a handheld device, with Android’s hardware partners taking advantage of the free rein given to them, going on to flirt with a variety of functions, icons and positions in a somewhat-wayward manner. In November that year, Google took charge of the playing field with the launch of the Galaxy Nexus, the device that pioneered Android 4.0 Ice Cream Sandwich, and with it, the first legitimate implementation of softkeys on Android. As has been the case with numerous such niches, Google taking a step caused most of the OEMs to fall in line over the years, and softkeys became prevalent on a wide number of device lineups.
The Impact on OEMS
Following the release of the Galaxy Nexus, things didn’t go exactly as planned, as most OEMs resisted the change, citing Google’s fondness for experimentation. However, year after year, Google continued down this route, and one-by-one, most device manufacturers responded in kind. Samsung for one, actively opposed the change, and for a while it seemed that the South Korean OEM was fighting an uphill battle, as HTC gave in with the One M8, Sony with the Xperia Z, LG with the G2 and Motorola with the Droid Razr Maxx, but a twist in the tale took place with the launch of fingerprint sensors.
As biometric authentication became increasingly popular, the hardware design teams at each camp were left with the mammoth question of placement. Where did fingerprint sensors belong? Samsung was quick to respond with an obvious solution, its home button, but others were left wondering, and the years 2014-15 saw various takes on the problem, but most notable was the tendency to resort to Samsung’s implementation, which saw large OEMs like HTC, OnePlus and Xiaomi go the home-button route, consequently causing each of them to give in to hardware buttons. Google and LG sport the sensor at the back, with Sony using the power button to house it, and while the world awaits Motorola’s take, two clear camps have arisen in the playing field, with powerhouses on both sides refusing to give up any ground.
A Deep Dive into Both Camps
With the market offering a variety of devices with both options to choose from, one might opine that it doesn’t make much of a difference, and while that might hold true for the average consumer, power users tend to carefully weigh the pros and cons of each device feature, so let’s take a look at the factors that constitute the gargantuan rift between the two manifestations.
The placement of softkeys on the lower edge of the screen causes a 48dp loss in screen real estate, blocking apps from availing the complete height of the screen. Some users think nothing of it, but hardware button enthusiasts vehemently argue that that space can be used by the system instead. Phones are getting larger, and the inability to experience the complete glory of a large, high-resolution screen is enough to send some over the edge. However, Google has been consistently working on making the best of the situation, deploying APIs that developers can use to hide the system bars and thereby provide a temporary fix.
Ease of access
Apps that hide softkeys, and the subsequent swipe-up gesture to show them is a notch against them given the mild inconvenience caused, but overall, hardware buttons prove to be much less friendly towards ease-of-access than softkeys. Their inability to adapt to device orientation hinders the user experience and the effort required to press them is considerably more than that required to press softkeys.
Hardware buttons are mechanical (or capacitive) in nature, with actual components making up their underlying structure. As such, their lifetime and durability are questionable, and have several variables such as intensity and frequency of usage, overall care of the device, et al, whereas softkeys are mere image renders tied to system-wide method calls, and are insusceptible to any such hindrances.
Adaptability and Modification
Perhaps the most significant advantage of softkeys is their ability to adapt as the situation calls for. Their virtual nature allows for the embodiment of Google’s “Design for the user and all else will follow” philosophy and there are a number of ways they carry this out:
While hardware keys remain locked to portrait orientation even when the device rotates, softkeys adapt and reflect the change in orientation, with the icons rotating to match the device on phones, and entire navigation bar changing the edge its anchored to on tablets. The result? A seamless user experience that sheds the learning curve and initial incompatibility when one attempts to use portrait-oriented keys in any way but that.
With custom ROMs allowing users to modify close to every inch of the system, the navigation bar is, without a doubt, an active and salient member of the array of customization options. From custom icon sets and manual height settings to modified order and user-defined functionality, softkeys allow for a level of personalization that remains near-impossible for hardware buttons, yet under-exploited in practice.
Mutation of softkeys is a new and unfamiliar topic, one that has been discussed from time to time on social media, and is just beginning to unfold in the Xposed community. Softkey mutation, should it come to fruition, would modify the navigation bar in a contextually-aware manner, allowing it to react and adapt to situation changes and thus providing a delightful and powerful user experience. While it might never see the light of day in the AOSP repository, community solutions such as Xtended Navbar give a glimpse of the potential held in the small black bar that so many oppose.
With all the facts laid out, it’s pretty clear that both sides have their own set of advantages and disadvantages. However, softkeys have infinitely more potential, and more importantly, the weight of Mountain View’s support. Like them or not, they’re here to stay for the foreseeable future. Which side do you root for? Does it affect your choice when buying a new phone? Let us know in the comments section below!
from xda-developers http://ift.tt/1NJLMzd