Web Scale, Online-Offline Architecture Pattern/Template for Tiny to Large Scale Products
Reading about and practicing myself many many architectural styles & pattern, I think I have something rather interesting to share.
I have identified a very standard architecture pattern, most online-offline systems can use (an online-offline system is a word I made up :) that supports both online/realtime & offline processing).
Its not new or anything revolutionary. It just works. digg follows most of that standard/canned architecture - app server - caching layers - storage - messaging/queues - async/offline hadoop processing.
Such architecture supports everything from small to large use cases and products. It supports processing large amount of data via hadoop while quick data queries uses the cache and datastore. App server is where the “online” business logic is. Offline business logic is in hadoop.
Its so generic & balanced that you can scale individual layers/components without affecting rest of the system. Also it fits in our SOA, where apps on the top are nothing but service end-points with no UI, or they can be java/node/php… apps with a UI.
I am not proposing, this is one stack that everybody should use, but its sort of an architecture pattern that works for many problems. You can skip components as you wish and add them later. For ex, for a mobile app/service we are currently building, we have no need for offline processing & a dedicated messaging layer - hence the hadoop & messaging layer goes away! We can add in the future if we want to - to add lots of stats, processing, etc..
So, you can scale it back to just the app server, caching and data store if you need, which is not that exciting or revealing, but you know you can scale it to ridiculous extent, by adding the async messaging & offline MapReduce/Hadoop processing layer. And bingo!!
Here’s the digg diagram. I chose not to build my own diagram because I am lazy. Digg’s diagram has most of it. Don’t get too carried away with their arrows. The important thing to note are the components and layers and the purpose they serve.
— Vishal
It’s not the consumers’ job to know what they want
If you think too much, you will make mistakes.
Will Amazon’s DynamoDB be a game changer?
My answer to this question on Quora -
I am very excited about DynamoDB and I definately think its a game changer. Its killer features are easy to get started, auto-sharding, dynamic scalability per table & proportional AWS costs/billing, in-place atomic updates, both eventual and strong consistency support. But Dynamo has some work set before it can really catch on fire - mostly around queries
- Much better integration with elastic map-reduce where I can seamlessly run MR jobs on the fly for queries, etc.
- Queries using key-filters other than range (only key filter supported at this time)
- Scan operation has a limit of 1 MB - the client has to do multiple trips if you have more than 1 MB of data in the table
- No index support other than the key itself. Riak supports secondary indexes for ex that are auto-built. You can build them yourself, hence not a deal breaker, but still..
PS. using solid state drives for storage is awesome!
Will Amazon make the Silk cloud backend available to other browsers?
My answer to this question on Quora -
I for one would think that even if they do open Silk, browser vendors will be less inclined to use it.
Google (Chrome), for example has its own cloud infrastructure, potentially bigger than Amazon’s.
Safari (my current browser of choice) traditionally is very conservative on using any 3rd party services due to Apple’s focus on simplicity - not a bad thing at all in my opinion.
Firefox can benefit potentially but fundamentally it might not be a big win and here’s why.
Silk/computing in the cloud primarily aids mobile (including tablet) devices - with limited network & cpu/memory resources. That’s when this really shines! - the approach of offloading some of the processing and caching on the cloud.
For desktop browsers, some of the above constraints sort of, vanish - more cpu/memory/caching capacity available. And hence the benefits are smaller, much smaller. In fact, it might even negatively impact overall performance, if Amazon’s cloud is experiencing a lot of traffic for example.
I do believe however that the hybrid processing and caching model is a terrific idea when well executed for smaller devices. But there is just not enough motivation as of yet for more powerful devices.
Managing User Presence, Software Caches, Counters, Sessions among other things using Redis
I have so many developers & architect choose the wrong strategy for managing user presence, caches, stats and session information.
My simple advice that works - use redis + expire. Its blazing fast, stupidly simple and very scalable using file syncing and replication and/or sharing.
Don’t try to kludge in using the old school way using sql or custom in-memory hash tables or memcached used inappropriately.
As a software architect, the hardest thing to do is pick the right tool for the job while balancing complexity, cost, performance and learning. And if there is one tool I never forget and keep on getting back to is redis which is an intentionally kept simple but superb artifact of the KISS principle. On top of it, its genius is behind its beautiful command language that is easy to operate and learn and more importantly build upon for very-simple-to-very-complex systems based on data models that uses KV alone. It takes a while to get used to but KV > Complex data systems for most situations, especially for session management.
You will find yourself using Redis for counters, stats, caches all while not having the cold start problem since Redis fsync’s (file sync) the memory representation so you can always lose a Redis instance and bring another back up without a sweat.
And the icing on the cake? It complements and not competes with other NOSQL, especially persistent, systems. I get amused when people talk or search for redis vs cassandra vs riak vs …
The closest you probably know related to redis is memcached.
API Design Best Practices. How to attain API Awesomeness.
API Design Best Practices
API’s can be fundamentally important for an organization. However, its use, contrary to popular belief, is not just for external clients & developers, but they can play an important role in building system wide applications & towards an API driven architectural style(more than in a separate blog).
So what are the good qualities to think about while designing APIs. In other words, I want to try to discuss, how to design APIs that are well designed, scalable (in its use) and some thoughts around related matters.
Qualities of good APIs
- Less is more
- The less the API set, the better.
- There are some obvious benefits here. Less means less to build, support, maintain. Its also supposedly easier to understand by API consumers, developers. Its easy to build off them as well.
- Sometimes there is a need for more powerful, custom APIs. In that case, my genius idea is to build another “set” of custom APIs on “top”.
- Ok, so what does that mean? Well, lets take an example. I have 3 simple APIs to offer to the rest of the world and to developers within my company. Now, I will offer another set of APIs that are built on “top” off these APIs with additional hooks and customizations. These APIs are designed for the power users, if you will. They are documented as such in a separate section. Now, what are the benefits of such an approach?
- Simple - isolation. Which allows us to “evolve” one set of APIs separately than others. This might not seem obvious, but believe me when I say, its tremendously powerful. I can add, deprecate a set of APIs, add/remove params without impacting my entire user base. This is awesome.
- I don’t know of any organization, large or small, formally following this. They might have such a pattern, but it often is an artifact of iterations, vs planned. Simply following this rule, will make you a better API designer, architect and developer.
- Simple - isolation. Which allows us to “evolve” one set of APIs separately than others. This might not seem obvious, but believe me when I say, its tremendously powerful. I can add, deprecate a set of APIs, add/remove params without impacting my entire user base. This is awesome.
- Ok, so what does that mean? Well, lets take an example. I have 3 simple APIs to offer to the rest of the world and to developers within my company. Now, I will offer another set of APIs that are built on “top” off these APIs with additional hooks and customizations. These APIs are designed for the power users, if you will. They are documented as such in a separate section. Now, what are the benefits of such an approach?
- The less the API set, the better.
- Loosely coupled to clients, possibly RESTful, platform agnostic
- Architects have learned the hard way, the cost of building tightly coupled APIs to clients. And I understand why they did that. APIs initially were needed to solve a problem, offer services to a set of clients and hence its natural for API designers to follow that client needs. Wrong 8/10 times. Clients come & go. That’s a fact of life. Both internal & external clients change, because they are often product focused and no product is constant, at least the successful ones. DON’T design your APIs for a client or a smaller set of clients. You will be amazed, at the possibilities of beautifully designed APIs. Systems are better built with loose dependencies on APIs as opposed to tight binary dependencies.
- REST is a very powerful pattern, that the web/http builds upon and you can not go wrong building RESTful APIs, but there are some gotchas. Don’t follow 100% REST terminology as chances are you will not have web scale routers and caching infrastructure. There is often something more needed. Also some of REST philosophy is hard to absorb. It’s OK. Start small, simple. Iterate from that point on. Learn from giants - Twitter, Facebook, LinkedIn, Google.
- Performant
- APIs are no good if they are not fast, simply put. Clients, often external, are dependent on them. Their performance, their user experience is dependent on your shoulders. And if there are 1000’s of clients, that’s a lot of responsibility. Don’t sweat it. Only expose APIs in the beginning that you know follow good algorithms, example does not involve an entire sweep of the database. APIs should mostly use keys to look up data, cache hard to calculate data and avoid user specific complex data to be served without designing & planning for it. Caches are API’s best friends. Take advantage of them. Assume clients will try to abuse them. You have to be smart, accountable & resilient.
- Keep responses small. Large responses are one of the biggest reasons some APIs are slower. Support pagination if there is more data. Simple. (See more tips in the response format tips below!)
- Consider supporting binary response formats for extra perfomance. msgpack, protocol buffers are excellent for compacting your API response and at the same time, supporting fast data parsing and loading, a great win!
- Don’t trust your clients
- This is something novice designers & architects always make. Trusting the clients to do the right thing. Wrong again. Never, trust your clients enough. Even if they are internal clients. Because even if the intentions are good, a small client application bug can suffocate API’s which in turn has down stream impacts.
- API servers are API servers
- API servers are often aggregators. They don’t have a lot of business logic, but instead depend on other systems to pull and present the data to the clients. Often from a variety of back-ends. If you are not doing this, in other words, designing or building APIs on your app server, well good luck. I will say, its a terrible idea. Even if you entire stack is hosted off one-machine, try to isolate the api server as a separate module, with its own dependencies and code base. There is only binary/library/API dependency on other modules/system components. You will thank me for this.
- Param Design
- Keep your param list small, very small for that matter. Give good names, so that 9/10 times I get it without reading a lot of documentation. These are for obvious reasons. As a rule of thumb, allways choose simplicity when possible. As API designers, this is the hardest aspect. As computer scientists, we are trained to solve complicated problems, but we are not trained enough on simplicity, the power of less, and all that. Just look at Apple products & user experiences.
- Clearly mark off optional parameters and document them separately, because many developers might not even be interested in that much power. Also, on the flip side, clearly note your default values for optional params.
- If you are designing HTTP APIs, follow the proper verbs. GET for data out. PUT/POST for data in or updates. DELETE for deleting data (use caution here, especially around authentication).
- Response design & formats
- Support only response format to the extent possible. Don’t try to be cool and support multiple formats unless absolutely required. JSON, these days offers a good balance of simplicity and client compatibility across the gamut of clients out there. I don’t prefer XML, but it works.
- If you need to support, more than one response format, try to isolate the view (the response template) from the data. This is inline with MVC design pattern. This will make it very easy to support & maintain multiple formats. And its easy to debug issues as well. Please note this!
- Keep responses small. Don’t include everything in the response.
- I have a great tip, that many don’t know. Use params to drive what to include in the response. This is a great way to give the control to the client and let them decide the tradeoff between performance and quantity. You should make this clear in the API documentation. Also, this can be designed as a priviliged service. Meaning, only priviliged (trusted, etc) can choose to include certain items in the response as they add to the response and/or cost more to calculate/generate.
- Real-Time Processing for Statistics & Monitoring
- Avoid doing real-time processing to the extent possible that is in regards to monitoring or calculating stats or for monitoring purposes. That’s because often times its not very simple to that in a fashion that does not compromise the API performance, and the integrity of the statistical data and taking other necessary actions.
- I have a much better idea to share for that problem. Do processing offline! What I mean by that is that you should log all the requests you get for the systems. Periodically process that data and calculate aggregate stats that the APIs can use to monitor and accept/deny/etc activities from clients. This is amazing powerful because it is very scalable. Offline systems can use hadoop/map-reduce on streamed scribe data and there you go, you can calculate the most sophisticated or the simplest of statistic, like API counts from a client or partner. Imagine, doing that in real-time, especially when you have 20 API servers and any one of them can serve API request. You have no choice but to use a distributed storage system and/or cache locally and periodically sync with other peers.
- Instead, doing it offline and updating the live API servers with that stat or making it available in constant time lookup (key lookups from caching systems or KV data stores for ex Redis) does wonders. Sure, there is a downside. You will loose a window of opportunity when the stat is not updated and you would still be serving clients. But you can have the offline batch processing as often as you like. For ex. every 15 minutes. That way, the worse you loose is a 30 minute window. And besides, you should be investigating DoS attacks among other things at the site level, not just APIs, and those systems can help/aid under critical attack or abuse situations.
- Authentication
- Coming soon!
Don’t be too much of a generalist where you don’t have confidence is yourself or what you build.
Be the change you want to see in this world
What Apple *now* needs to bring even more & better apps to its platform
Summary
I seriously think that supplementing iOS’ development features to support building native apps via a dynamic programming language like JavaScript or Python/Ruby will change everything one more time. The pace at which developers can then build apps will be phenomenal, and it will further help attract web developers to the iOS’ native platform. Furthermore, this will become Apple’s contribution to further support for what I believe will be the foundation of next-gen applications, which will be built using hybrid designs - part native, part HTML5 - the native layer for following the foundation and the core structure of the application and the web/HTML5 layer for content display which can be easily changed on the server side.
Apps & iOS
Technical and Technological marvels in the making
The iPhone & iPad are simply put, technical and technological marvels in the making. If you just knew what’s packaged in those shiny looking little bricks, you would know what I am talking about. And if you know a thing or two about design, you have seen how beautifully the hardware and software are fused together to make a complete whole. Its truly beautiful.
Beauty and the apps
No doubt the sheer beauty combined with the focus on simplicity has helped Apple turn them into instant successes. Both don’t ignore the all the apps out there - the apps we love, both Apple and 3rd party; the games, the camera apps, the utility & productivity apps, the news apps, that beer simulator app. Apps define who apple iPhone users are and they are one of the biggest reasons, the iPhone is where it is today.
App Development redefines the mobile OS
Apps today are the centerpiece of the iOS. The OS itself these days mostly evolves around better supporting applications - how to be fair to all apps, yet act judiciously on behalf of the user. You will not believe how much time and effort is spent by Apple on just app development tools, frameworks, libraries. You will also not believe how much the OS itself is developed with apps in consideration. And so much of the OS code is devoted to this particular aspect. The iOS would be of many magnitude simpler if Apple would have chose to keep it locked for internal apps only. Then again iPhone and iPad would not have been the same without 3rd party apps. There would not have been Angry Birds and imagine your iPhone without it. Bottom line - Apps are centerpiece no matter how you look at iOS.
Dynamic language support
Easier app development - why not?
If apps are centerpiece, and if I was at Apple, I would seriously think about getting even more and higher quality apps in the appstore. Its just a win-win situation, isn’t it? Win for Apple. Win for app developers. Win for users.
Today native app development with Xcode is fun and tooling from Apple is simply phenomenal but apps today are developed using Objective-C, a language originally developed in the 80’s. Sure, it has evolved, there is a 2.0 version and the team has done a terrific job adding features such as automatic reference counting (ARC), a compiler feature that makes it easier for app developers to manage with the app’s memory space and leaks. But it still is quite a chore to program in when compared to dynamic programming languages such as JavaScript, Python, Ruby, etc.
Just ask a developer how to filter an array of values based on some condition in Objective-C vs say in Python. And just sums it.
I actually like Objective-C and it certainly needs to be there. Power developers and apps with complicated development requirements can very much benefit. But a good 70% of apps can do away with it and instead opt for the much simpler dynamic language route.
Some of the benefits of dynamic language over static languages include - * No compiling of code at development time * Loose typing aids in quick development * Higher level constructs such as cloures/blocks and functional programming paradigms are more easily supported with dynamic languages * Ability to build iOS apps without learning a new language (and trust me Objective-C is quite an oblique language to many developers new to Apple development) * Code and library reuse across web and iOS native applications
Does a particular dynamic language matter? Or do we only need dynamic syntactic sugar?
Apple has couple options to support dynamic languages for its iOS and Mac platforms - 1. Choose an existing dynamic language such as JavaScript or Python or Ruby 2. Come up with Apple’s own Objective-C variant of a dynamic language
I don’t think it matters that much, but option 1 to me appears to be a no-brainer.
How to build dynamic language (DL) support for iOS? What are some of the challenges?
I am afraid its not as easy as picking a dynamic language and saying done. There are caveats and decisions to be made. Would I support building full fledged apps using DL or would it be smaller subset? Apple faces some really tough challenges, since it has not supported non-C based programming languages in the past. Other platforms such as Java and .Net use a common runtime layer that other languages translate its code into and the common runtime code is what at the end of the day gets run by the hardware. Unfortunately its a little late for Apple to build such a layer. And its a complex tasks with questionable returns.
Hence, the only option I see fit is to support a translation layer. A layer that translates dynamic language code to low-level C code. This in theory is similar to Google’s GWT (Google Web Toolkit) which translates Java code to optimized JavaScript.
The key is that code generated is heavily optimized and that the generator understands platforms such as iOS and Mac. However, I don’t think its a terribly hard assignment. Nor one that changes much for Apple. Apple continues to base its frameworks and OS on C-based languages and Objective-C, while giving developers the choice of developing with Objective-C, a static programming language or an even higher level dynamic programming language.
What’s the cost to support Dynamic Language (DL) on iOS?
The cost involves around - * Building the DL to SL translator & generator * Tooling to support the language in Xcode and tools such as Interface Builder and Instruments. * Documentation to aid developers * Bringing some of the conventions and best practices from Objective-C and C to DL based app development
There are no significant runtime or OS level changes. The thing however I am most worried about is bullet #2 above. Xcode is quite a complicated piece of software and I fear incorporating a DL might be non-trivial, but its hardly impossible.
Also, Apple developers have learned to follow a lot of conventions and nuggets of wisdom that might be a bit difficult to translate to the DL layer, but I do not see it as a show stopper.
Think about the upside. Think about the benefits if Apple say adopts JavaScript. HTML developers can rejoice and start leveraging their JS skills to build native iOS apps. What a dream come true. Sure, they will not be able to build sophisticated OpenGL ES games with it (which too is a possibility, look at WebGL) but they can build fairly sophisticated apps with it without learning a new language and dealing with lower-level memory management constructs. And the hardcore Objective-C developer can continue to use what they do today.
Hybrid Apps
In fact, what I would be most excited about is (shhh, its a secret) is the ability to build apps using a combination of dynamic language for some parts of the application and Objective-C or C for the rest. This can be a powerful concept that I can’t wait for! If I were to build a simple photo sharing app, I can start building the UI with DL and leverage Objective-C for photo editing and possibly network optimizations if needed.
Conclusion
I love dreaming about hard problems, and this one kept me busy for a while. But I do believe this at least warrants a R&D project.
Vision without execution is hallucination
Source: blogs.ft.com
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.
