Android Keyboards in India

Why don’t Android phones sold in India come with Google’s Indic keyboard set up as default?

Specially for phones that don’t ship with proprietary/3rd-party keyboards, doesn’t it make a lot of sense to pre-install Indic keyboard over the default English keyboard?

It’s such a small step, yet can be quite a big enabler for the users (and, even, possibly a differentiator) – using the power of defaults to deliver a better user experience!

A case for splitting up the WordPress mobile app

Venn diagram of readers and writers on WordPress, specially on mobile.
Readers vs writers on WordPress

By integrating ‘reading’ and ‘writing’ in the same app, you’re forcing the bigger user group1 to also confront tools designed for the smaller user group.

On mobile – skewed by design more towards consumption, than creation – I assume the disparity in these two user groups is even bigger.

Having a standalone reader app, allows it to reach a much larger use case – ‘Help people follow, read, discover’.
Compare this to current use case – install it if you…

  1. post to WordPress frequently from mobile, or
  2. love reading in WordPress reader, despite having little use for other three tabs – write, manage, and notifications?!

A really good standalone reader helps plug in a singular user need2 – reading. That need, in terms of following blogs and websites, only rarely overlaps with the other need that the app currently fulfils – writing.

Though it will place it in competition with feed readers like Feedly, it also has 2 unique benefits as well:

  1. Close integration with a writing platform (related posts, comment & like directly from reader),
  2. The abandoned Google Reader audience that just wants to follow and read feeds, without being overwhelmed with magazine interfaces and more.

A good, successful reader mobile app with large user-base will, eventually, help close the RoI loop: suggest (through ‘discover’) other WordPress/Jetpack blogs, creating an incentive (or delivering reward) for creators using WordPress.


  1. One definition of readers and writers:
    – Writers: 7-day active writers – users who posted at-least once a week.
    – Readers: Unique visitors per week – including logged-in users, not-logged-in readers, and from feed readers.
    Another definition (more relevant to determining use case ratios):
    – Writing: Posts /week.
    – Reading: Page views /week – again, including not-logged-in readers, and from feed readers. 
  2. Should some day also write a similar, smaller, post on WordPress Calypso’s interface – how it needs to be split from current two, into three sections. Currently, the ‘write’ and the ‘manage’ use cases are mixed into the same tab, while ‘read’ is in its own.
    Ideally, ‘write’ and ‘read’ – each a singular, frequent use case – should have their own tabs. ‘Manage’ can be in a far-removed tab, or behind a ‘manage’ button. 

Facebook Android app – a UX minefield

I’m sorry. This is yet another post1 on more UX/UI mess that keeps bothering me.

Starting with something I recently started using after 8+ years – Facebook. FB earned a reprieve from the tech press after its change of heart on native smartphone apps. But their Android app is still way below par for what is the primary user interface for vast proportion of their users.

Here are 2 bits that bugged me right away…

FB Issue #1 – In-post touch areas

Touch Targets - Facebook Mobile
Touch Targets – Facebook Mobile

Facebook states that stories/posts that are posted natively get shared more widely to the followers, compared to those posted as links. Yet, the mobile interface makes it practically impossible to click-through to read those very natively-posted long posts.
Continue reading Facebook Android app – a UX minefield

App Splash Screens – The Good, the bad and the ugly

I’m not a fan of app splash screens. They delay app usage without presenting any useful, or even pleasant, information or interface. To me, they imply either:

  • badly thought out app design requiring loading loads of data before the UI can even be shown, or
  • a pathetic branding attempt that spoils UX by unnecessarily delaying app access

Here’s some thoughts on how to (not) do splash screens in apps:

The Ugly

My pet favourite object of splash screen hatred is the MyFitnessPal app. It has not one, but 2-step splash screen. The first one shows a progress bar, which I assume shows the status of data stored locally on my device.

Myfitnesspal - Splash screen stage 1
MyFitnessPal – Splash screen stage 1

This is followed by another phase of splash screen madness under the Synchronising data title with a rotating symbol this time (so no indication of progress).

Myfitnesspal - Splash screen stage 2!
Myfitnesspal – Splash screen stage 2!

Only after the local data has been ‘loaded‘, and synchronised with the servers, is the user allowed to see the app UI. And despite this, the headline daily dairy numbers they show on landing screen is wrong most of the time. Specially if another app (Garmin Connect for me) has synced exercise calories with MyFitnessPal.

This feels so wrong. Why can’t they just show me the default landing page UI right away, letting me do what I do on most app uses – log food consumption – as quickly as possible. The changes can all be synced in the background.

The multiplicity of logos on the splash screen, as well as several other UI decisions in the app seem to convey that MyFitnessPal has a weak UI/X team being overridden frequently by a politically strong marketing/content team.

Continue reading App Splash Screens – The Good, the bad and the ugly

Tizen viewpoint – Sept 2011

I wrote this note on Tizen last September when it had just been announced. Someone I was pitching for work to, had asked me for a brief note on Tizen, and this was my submission. The recent announcement by Samsung about merging Bada with Tizen reminded me of this note and so I decided to post it here. [Having just read it again, it again showed how quickly this industry changes – what seemed so unlikely a few months ago seems one of the likeliest outcomes now.]


The Background

The Tizen project is a coming together of multiple organisations, OEMs, Intel, Linux Foundation and maybe even telecom operator, with unusually varying motives and thus has both the advantages – becoming a widely accepted industry standard – and the disadvantages – lack of ownership and direction – of any such project.

The OEMs have for some time now been in a struggle for control of industry profits and dynamics with the big three platform owners – Apple, Google & Microsoft. Till recently, Google with its open, free & independent Android was the platform of choice for these OEMs. However, all three of those qualities of Android are now in doubt thanks to Google’s pending acquisition of Motorola, Microsoft’s patent taxes and moves from Google to tighten control over development and deployment of Android.

Intel has long been trying to get a foothold in the smartphone industry, where ARM designed chip-sets dominate. With mobile OS platforms being adapted and extended to tablets, TVs and other connected devices, Intel realises that it could be left out of a huge and fast growing market catering to all possible connected devices. While MeeGo and its AppUp store may be part of its attempts to develop a complete platform, at its core Intel is fighting for relevance as the industry moves towards a low-energy, connected device environment.

For LiMo and Linux Foundation, this coming together of Intel, OEMs and, possibly, some mobile operators may present an unprecedented opportunity to promote Linux’ acceptance as a wider consumer platform. Being committed to an ‘open’ environment, Linux Foundation could also provide a neutral outlook to Tizen by ensuring no single promoter could lock-in the platform to its own proprietary technology.

On the technical side, the development and widespread acceptance of HTML5 standards opens up another opportunity for a new platform. When combined with the Linux core of LiMo or MeeGo, HTML5 obviates the need for an advanced set of proprietary tools to enable app development while allowing for quick porting of applications from established OS platforms. This had been a handicap for both LiMo and MeeGo with the requirement of native apps and, Nokia-owned, Qt apps, respectively.

The Strategy

Although the background to announcement of Tizen seems clear now, the future strategy is still a little hazy. However, considering the primary goals of key backers, a possible strategy for Tizen may be to develop the core OS and a set of development tools, with a very basic platform of content and services around it.

This would allow its key supporters – the OEMs, Intel and telecom operators – to customize the platform to their own individual needs and branding. All of them also want to independently capture the benefit of content sales flowing through their devices or networks, and an open, independent platform may suit their needs better. Intel would benefit by reducing the control of big three platform owners in deciding which chip-sets may be supported and ensuring Tizen is fully Atom-compatible.

One aspect critical to its success, though, will be support from app and content developers. Use of HTML5 as a development platform eases the transition path for developers but without a single large market or a strong promoter (like Microsoft with WP) backing it, developers might be vary of committing to the platform. Also, remaining to be seen is the DRM support on the platform – a lack of which may keep off content producers.

Ultimately, solving the riddle of ‘Which comes first – Apps or Customers?’, may require strong actions from Tizen’s backers beyond making announcements. These actions could be in a form similar to Intel’s recent $300 million Ultrabook fund, incentivising developers for apps and content for Tizen and OEMs for using the OS along with Intel’s AppUp store. Quick release of an SDK with a set of APIs and the initial set of devices will also encourage the developer community to take the device seriously.

The Future

Over the longer term, the biggest determinant of Tizen’s future may not be its own development, but how the industry dynamics with other OS platforms play out.

Of the various scenarios possible, the one best suited to Tizen’s success is one in which the bigger OEMs and Intel perceive themselves being further restricted by big three platform owners, are unable to promote their own OS platforms, and see their immediate bottom-lines threatened.

However, in an alternative scenario, if Google decides to sell off the OEM bits of Motorola, resolves the patent issues surrounding Android, and comes to a mid-way understanding with the OEMs over control of the interface and content, it can still rally the independent OEMs behind itself and cause the Tizen initiative to flag.

Also, if the big few OEMs – mainly Samsung and HTC – decide to bet on their own OS platforms by developing in-house (e.g. Bada 2.0) or buying orphans (like WebOS), it could still weaken their support towards Tizen’s development.

At the moment, Tizen is an outcome of spread betting by leading industry supporters while they see how the industry dynamics resolve themselves. To be successful, it will require strong support in terms of development, incentives and new devices from its promoters but that stage is still some time away. Till then, the core OS itself may continue development but as a platform it is likelier to follow LiMo’s graph than that of Android.

Platform + App + API = Shortcut to Win

As a cyclist, I keep exploring route mapping and live tracking apps. This weekend it was the turn of mapmytracks, thanks to all the attention focussed on rocket2 LEJOG attempt.

But this post is not about a route mapping / tracking website, or about that attempt. It’s about the interesting approach mapmytracks has taken to app development.

They’ve developed official iPhone, Blackberry and Nokia apps. They don’t have an Android app, yet, but openly link to alternative Android apps that work with their API providing both live tracking and route mapping.

I like this approach, coming as it is from a website in a cluttered & competitive space. By providing an API and advertising / linking to compatible apps, they don’t have to compete with the huge number of similar apps in Android marketplace. Yet, they enable people on the most widely used smartphone OS to connect to their platform.

In one move, they’ve reduced their own efforts towards developing an Android app, ensured presence on multiple apps on that platform, and yet given them the option to, some day, buy the app that emerges as most successful on Android.

Wondering:

  • Are there other small firms out there, developing and owning the platform while providing APIs and encouraging outside developers to provide mobile apps for it?
  • Why don’t more startups that are targeting to become a ‘platform’ use this with an app+api strategy?

Continue reading Platform + App + API = Shortcut to Win