Android Thoughts, Insights & More
We are very happy with the Ask Android app that we recently launched. I am particularly excited for couple reasons - Android users now have a great way to access Ask.com and our fantastic new Q&A service called Ask People. And secondly, we now have a solid foothold in the Android ecosystem and this to me appears to be just the beginning.
More than just mobile
Android is more than an OS. Its a complete platform including an OS + frameworks & tools to build great mobile (and soon TV among others) user experiences. There are plenty of Android devices around and more are on their way, and to me, the most interesting thing about Android is essentially the limitless possibilities one can take advantage of due to nature of its design & applicability. Devices with different configurations, sizes, shapes and uses, all are welcome, and with the additions like the Android Open Accessory Development Kit (ADK), various USB powered accessories can be built to connect with Android devices for command & control like this (PhoneDrone Board). This is an area Apple has shown less interest and something Google is clearly trying to capitalize on. For Google, it occurs to me that, Android is hardly targeted to be a mobile OS. Maybe it started as so, but that’s just scratching the surface. It certainly is approaching to be more of a general-purpose platform appropriate enough to run on pretty much anything where traditional OS’s fall short as they carry too much baggage. Heck, it even as support for non-traditional, non-touch interfaces. Google TV for example, allows users to interact with the use a wireless remote with an optional keyboard. Today, if you are in the business of making any hardware with user interactions including appliances, automobiles, toys, what have you, you should take a serious look at Android. Chances are you will be amazed at the possibilities. You will have the option to build upon a general purpose light-weight OS that supports many forms of interaction modes with an very good Java based application framework and connectivity via cellular networks, bluetooth or wifi, allowing you to build applications that embed deep social experiences into you platform.
Android - The Good Parts
Notifications
I was impressed the minute I saw Android’s notification panel. Its a bit late to applause as iOS has followed suit, but kudos to Android designers for thinking it through and paying attention to Notifications in detail.
Widgets
Android’s support for widgets is similar to Mac’s Dashboard and its great. It lets you attach mini views that are rich and support network based content such as weather. Its not just an OS feature, but a user level interaction pattern that saves the user from launching the app for trivial use cases, such as checking the weather.
Developer SDK
The Android Developer SDK is very well thought of and designed. It follows many established design patterns and to make it very easy for developers to dive in and start building apps quickly. I was impressed by the XML based markup language for layout authoring which also can be manipulated dynamically if needed. I also appreciate Android’s support for alternative implementations for core apps such as dialer and maps and a loose communication mechanism that allows developers to promote their features across apps. Android certainly strives to be as open as possible to encourage manufacturer and developer adoption on a broader scale, and the design of the Android SDK nicely potrays that aspect. The SDK documentation is terrific as well. Kudos to the Android team for that.
OTA updates
Android’s support for OTA (over the air) upgrades is great and something iOS is following suit with iOS 5. It reminds me of Palm’s WebOS where OTA updates and sync’ing of the data was at its core.
Ripe for hardware innovation
Being an open eco-system really fosters innovation, for both hardware and software. For example, just recently HTC released the EVO 3D phone. Its a phone that uses dual 5-MP cameras to let users capture 3d photos and videos and they can be viewed without 3d glasses (like the Nintendo 3DS) using a qHD display. That’s just the hardware piece. HTC has also made some very interesting Android enhancements such as adding a dynamic widget system on the lock screen so you can check for example weather without unlocking the device - very handy. There are also enhancements made to the notification tray to include quick links to common Android apps such as Settings and include a tabbed interface for quick access to specific settings such as turning on/off WiFi.
Enhancements like these can only be made if a platform is open and I really appreciate that part of Android, but at the same time I gripe about the lax of hardware and software guidelines. I like the open ecosystem, but I think there needs to be some consistency just so the manufacturers and software developers don’t try to go overboard. The Android platform should strive to make it easy for users to switch devices, in fact that should be encouraged.
Android - The Not-So-Good Parts
Not all is fun and games when it comes to Android and developing for Android, in my opinion. There is lot of room for improvement and there are some fundamental concerns I have with the platform, its design and capabilities. And I would like to share some of my thoughts around it.
Android hardware/device implementations & guidelines
Although, I have never looked at Android’s recommended hardware guidelines, like I mention above, they appear to be pretty weak or in other words, very flexible. Flexibility is great for manufactures. It gives significant freedom in designing their own devices. After all, Android is just the software stack. But there is a catch, albeit a big one.
Many device manufacturers make Android devices, but the flexibility left in hardware implementation guidelines makes it extremely difficult for users to switch between Android devices. Here are just couple examples why-
- Power button - Even if you use just a couple Android devices, you immediately get in trouble finding the power button! Yes, that button that gets the device on/off sleep mode. Just go to a shop and try your luck. Lax hardware guidelines here make end users pay here.
- Hardware buttons (especially the back button) - Most Android devices have four hardware buttons (newer devices seem to have made them soft) that work closely with the device’s interface giving users a quick way access certain features. Although that sounds great, some manufacturers have in fact chose the order of the buttons at their will and biggest complaint I have is with the back button. Its one of the most used buttons and its very difficult to adopt to its different positioning. Also I am not sure whether having four physical buttons is a good idea. Its hard to pick the middle two without looking at them first as most devices have these as touch sensitive and hence there is no bump to differentiate the button boundaries. I personally think, having just one button like iOS results in a much simpler user experience. Anything else can more easily embodied in the home screen UI. I worry that saving couple taps here might have caused more trouble here than deserved. Sometimes its not just efficiency that you have to think about. You can not treat all problems as optimization problems. Sometimes upstream optimizations have unintended downstream impacts. And that’s one of the biggest concern I have with Android. I am not sure if its due to competition or differentiation, but there are some serious optimizations in place that I fear would bite the Android community in the end.
- Form factor, screen size, density and resolution - This is another area where I am not too happy with Android team’s decision to allow a lot of flexibility to device manufacturers. I would have instead chosen a base screen size and resolution and allowed manufacturers to increment/decrement yet sticking the base scale and few specific scale points are allowed (ideally less than 5). This is a fair compromise between flexibility and consistency. Its a win for both consumers and developers, as the scale and scale points are well defined.
Now one would think, these are hardly a big deal, users can get used to such things in a matter of day or two. But that’s hardly the point. If Apple’s iPhone proves anything, it will be that most users will be upgrading their devices more frequently than ever before, and everytime a user upgrades, there is a high likelihood he/she will have to change their habits to get accustomed to such nuances. At what cost? So that hardware manufactures can choose such hardware factors as they wish? Maybe that’s a good thing, but the way I see it, there is high value in consistency. A device advertised as an Android device, should mean something, something more than just the software powering the device according to me.
Android software and user experience concerns
Back button
I personally think introducing the back button in Android was not the best decision made by the team. Wise designers and engineers know, you have to be very careful when trying to introduce a new interaction pattern, and even more when its something foundational. And the back button is one such thing. Its at the heart of everything Android from a user experience stand point. Its THE way to go back to your previous screen, activity or application. You better get it right, else there will be consequences.
Now there is certainly an efficiency gain here. Introducing the back button gave Android developers and users couple things - 1. Extra real estate where generally the back navigation button would reside. Great for those who like this efficiency gain (again, in my opinion not everything can/should be optimized, but I get it). 2. More importantly, introduce a consistent pattern for apps to allow users to navigate back to whatever they were doing before. 3. Last but not the least, introduce a way to quickly go back. Just like browsers, most apps have back, forward functionality.
Now, these are great! How could you go wrong with that? Well, I am here to argue otherwise. You can go wrong, in fact, very wrong. Let me share some insights on the two points I mention above.
- The extra real estate is not all waste. The navigation bar serves an important purpose. This might be obvious to designers and savvy developers. It serves as a header for the screen and the back button actually is very visual and gives a very clear indication to the user how to go back. Its visual and that’s what makes it so effective. With that navigation area almost redundant, many application developers, including Ask, had to remove the top navigation bar, as we too chose to follow Android’s recommended back button to go back to the previous screen.
- Unfortunately one thing Android designers glossed over was how users are so very accustomed to the back interaction pattern, solidified by iOS. Android was a newer OS and although innovation is great, breaking new ground is great, thinking outside the box is awesome, this is an instance where sometimes it backfires. The navigation was a very well established interaction pattern set by iOS and I do not believe there were any indications of it not being effective. Blowing it off has consequences, and unfortunately myself and all Android users will have to deal with this decision. Its especially bad for folks who come from a iPhone device or those who have multiple devices in the family, one iOS based and other Android based.
- Our own Android app hence had to behave differently. Many of us are both iOS and Android users. And Android designers unknowingly added an extra mental block upon us; to remember to use the back button on Android devices. A very unfortunate consequence. I can see the other side of the argument. Android being android would sometimes like to do things differently and simply not follow. But this one has just too big of a cost to be justified in my opinion.
- This one is rather more interesting as you might never guess this one. The back button pattern requires the developers of ALL the apps out there to generously follow the back pattern. Sure, you can make it easy for them to implement and even by default the behavior is free, its not enough for developers to clone their iOS app UIs or come completely ignore it as many simply do not understand it completely.
- The argument to quickly go back might seem valid, if you appreciate good design, you might realize that this is unbalanced solution. - why just using the back button get special treatment?
Unfortunately, its too late to change. Us Android users, will have to just live with it. That’s how powerful the impact was such a decision made of introducing a dedicated back button. Once introduced, its impossible to take it back! Good designers realize this and hence are a lot more careful before introducing such disruptful behavior. Often times, disruption is good but like I said earlier, its not always about efficiency. A good designer knows the importance of balance.
Hardware Acceleration & Memory
Another interesting aspect of Android devices is inconsistent hardware-accelerated rendering of 2D graphics. One of the concerns users have with Android devices is that UI rendering and transitions are not as silky smooth as users are accustomed to seeing in iOS devices. That’s because prior to 3.*, GPU based hardware acceleration was at best spotty, whereas iOS devices by then supported smooth GPU based acceleration offering beautiful screen draws and transitions. And to add insult to injury, Android apps suffer from the occassionally to frequently (memory) garbage collection pauses. For the non-computer scientists, what this means is that because Android apps are written in the Java language, where a background sub-process periodically cleans up the memory of discarded objects. In iOS on the other hand, developers have to take responsibility of cleaning up themselves (with newer systems such as ARC simplifying that effort) and hence does not need to operate this background process to “garbage collect”. In our testing, garbage collection often causes significant pauses due to its nature, being a heavy-weight process which in turn could result in small hiccups from a UX standpoint, for example while scrolling a long list of photos. Developers do have access to tools to analyze and monitor these collection runs but most developers tend to ignore them until its too late to make significant changes to their app. Garbage collection pauses along with inconsistent hardware accelerated rendering hurts Android user experience today. If you are used to iOS UIs and animations, you might be a little disappointed when you try out some of the Android devices. Android 3.0 did introduce hardware accelerated 2D graphics, but unfortunately most users are still on earlier versions.
Android Dashboard
Android’s home screen is the first screen you see when you use an Android device. It behaves similar to a desktop on Mac/Windows where it has app launchers for chosen applications as opposed to iOS’ all app dashboard as opposed to all the apps available. I have found that to be a bit confusing, even though its so prevalent on desktop computers. Part of the reason I think is that for mobile devices, its a bit awkard to click on an icon to see all your apps. I think its a great abstraction to keep the home screen clutter-free, but it also means that every time you download an app, you have to use two taps to get to the app launcher. You can add an app launcher to the home screen but its work that can be saved. And the argument against clutter can simply solved by introducing folders or using the additional screens for organization (like iOS).
Poor native UI controls and apps & Manufacturer customizations
I was not very impressed at the look-and-feel of native UI controls. Below are some of the out-of-the-box UI controls available to developers, I was extremely disappointed when I first looked at them. It appears that intentionally very little emphasis was put on the design of these controls! Granted, I was an iOS user before Android and accustomed to simply drop-dead gorgeous controls, I wish emphasis was put on this, because most application developers take advantage of them, and they should (dont invent your own controls, unless absolutely needed!) and hence in turn developer applications are impacted. And this indirectly encourages developers to customize or re-design controls, which leads to an applications with inconsistent UIs, a big no-no! And to add insult to injury, many device manufacturers further customize the appearance and look-and-feel of Android UI controls.
Contrast that to iOS’ consistent and just drop-dead gorgeous controls and I as an UX enthusiast immediately become psych’d to build apps using such controls.
And in fact iOS designers encourage to further push the envelope and build upon using ridiculous beautiful UI controls such as one below pulled from Apple’s iOS Human Interface Guidelines.
Scrolling and the bounce!
Android designers dismissed what I think one of the most important UI artificats of iOS - the screen bounce. When you reach the end of content (such as a list or a web page) in iOS, the OS gives you a “visual” indication of that by stretching the screen with a blank canvas behind, indicating simply that you have reached the end of content. Its visually delightful.
I was very disappointed to learn that Android designers dismissed that simple UX artifact (or maybe there were other restrictions to including it, such as legal). To me, its an absolute no brainer and I am unaware if there are patent restrictions, but I would have tried to bake that in. In fact some Android device manufacturers have customized and included the bounce, further fragmenting the OS guidelines and look and feel consistency across devices. And sometimes, at the cost of added complexity, designers can choose to add a setting that can disable the bounce feature, but I would not completely shun it.
Developer nuances
Some developer nuances that I think Android leads should think about -
Android Emulator
Android needs a much better and faster Android emulator. I can understand however that its challenging because the Android SDK supports development on all 3 major OSs - Mac, Windows, Linux. Which adds serious complexity when trying to build a fast but beautiful application. At least for Google TV, they chose to build a much better emulator by only supporting Linux and optimizing using KVM.
Application Tabs
Its very tricky to get Android’s tab UI to work out of the box with the back navigation when you have tabs that drill down into content. This is an area where we had to spend significant time and energy and author a solution just so the back button works as our users expect! This is another use case where a visual back button simplifies and better solves the problem, but by consequence of introducing that, we worried we would confuse the end user by using a combination of hardware/back and visual soft buttons for going back. Its best when there is just one way of doing things in my opinion.
Web browser embedding (WebView)
We were also not super impressed by Android’s mechanism to embed the browser control within apps. My prediction is that increasingly app developers are going to choose to use this as this allows for reusing a content provider’s mobile web (HTML) pages within an app. We ran into some obscure bugs and issues with it. If we had the resources, we would ideally contributed help to the Android project towards enhancements of the WebView control.
Poor Maps Integration Support for Apps
Despite the Android SDK well designed, the maps library that app developers use to integrate Map support within their apps, is very poorly designed and despite being the most popular API on the planet, I am surprised at how much mediocre the library is. The problem in my opinion is that Android designers chose to make the library as a separate component vs something that was designed and built as part of the SDK. It appears to be an after-thought, much neglected component, which is too bad, because many many apps love to integrate maps functionality one way or the other.
Android 3.*, Tablets and Forward
Unfortunately for Android developers at this point, most Android cell phones are on a 2.* version of the Android OS. But there were some great Android enhancements made for Honeycomb version of Android and above, such as layout fragments, which lets a developer break up and decompose the application’s UI and functionality into bite-size modules that are much more easier to develop and manage over the long run. Furthermore, these modules make the task of supporting cell phone screen sizes and larger tablet screen sizes much more easily, as most of the time, the developer just has to rearrange or identify screen size specific fragments.
Hence, current Android developers are much stuck in a dilemma. They are many more enhancements that are part of 3.* versions such as a much needed action bar pattern, which developers can follow to better organize common controls such as settings and search while at the same time make it easier to use and get accustomed to because many out of the box Android apps use it, such as the Mail app.
Unfortunately most application developers target the popular mobile phones based off Android vs the much less popular tablets and hence there will be some challenge, effort and learning curve to get their apps properly designed and developed as to meet the highest standards for tablets and larger screen devices.
I wish 3.* was more quickly available to mobile phones as well, so as to challenge developers more quickly on using the new tool-set and UX patterns and feature set. At this point, most developers are simply waiting and watching in terms of identifying when and how to penetrate 3.* version’d tablets.
Concluding thoughts
Android has already proven to be an extremely successuful platform and its openness has attracted many hardware and software vendors to invest in it and build entire product lines and businesses on top of it. Despite, the many concerns I describe above in terms of user experience, consistency and hurdles caused by the slow adoption of 3.* versions of Android, I think the Android SDK is beautifully designed and a pleasure to work with, and furthermore, the Java programming language makes it incredibly easy to build applications for Android, especially for novice developers. The learning curve as well as the bar is much higher for iOS apps.
Inconsistencies in Android software & hardware devices do, in my opinion, take away some of its shine, especially considering the amount of energy, time and expertise Apple pours in to their hardware & UX designs.
A mobile phone or a tablet are devices many users get very attached to. To them its an extension of who they are and what they do. And the amount of things you can do these days with them, puts traditional desktops and laptops to shame. And it pays for such devices to be drop-dead gorgeous, beautiful and simple to attract users in numbers. Android has had the marketing & distribution piece worked out. I strongly believe the Android team has a very tough road up ahead. On one side, the penetration of the Android OS and device numbers are simply staggering, the challenges they pose are, I believe, even more staggering - Its difficult now to radically change things, once you have that many users already using Android products, and I think, there is definitely work cut out for them for next couple releases to become a serious contender to iOS not just in adoption numbers, but in terms of style, usability, feel and the experience of the entire product - software and hardware combined. Apple does have a unique advantage, as it builds the hardware and software components itself, and hence are in a much better position to build devices and operating systems that work seamlessly and in harmony. If I were an Android lead, I would invest a lot (and I do mean a lot) more energy working with hardware manufacturers, and connect the dots on some of the items I highlight for example, as they in turn will lead to the kinds of products that can build empires.
