App Developers : You Have To Cross DALDA Barriers


App Developers : You Have To Cross DALDA Barriers

When I was a kid (in the 1980s!), one of the most unhealthy things in the kitchen used to be “Dalda” (a brand of Vanaspati, which became a generic name, like Xerox). Several health problems like cholesterol were noticed in a lot of people consuming Dalda, typically in the middle income bracket. While we may call those as “Dalda problems”, this post is not about that. Then?

I did a talk at Nasscom Foundation event recently to some startups on common pitfalls in mobile app/solution development in emerging markets:

This is just a summary of that. Why Dalda? Read on.

Building mobile app/solutions for emerging markets need to cross the DALDA barriers (again!) before they can reach their users.

daldalogoDevice Barriers

Emerging markets have various kinds of phones with various kinds of operating systems, various kinds of screen sizes, various kinds of resolutions and various kinds of.. you get the point! Decide what is your target device list & ensure your solution works well on those.

If you need to support Java, do not get into the minefield of app development. Just support over WAP sites, SMS or USSD.

If you think you will do Android and there is not going to be any issues with it, sorry, that is not the case. You cannot have your flashy designer create designs using the animations possible with the latest ‘material design’ and expect it to work on a Galaxy Ace phone released in 2011 with Android Gingerbread. And there are tons of devices still running on Gingerbread.

Then comes screen sizes & resolutions (they are different things and many people realize it too late), internal memory availability and so on. You could build the greatest of the app but will the Galaxy Ace with 190MB internal memory allow to install it? Is the user going to remove Whatsapp or Facebook and make space for your app? Less likely, right?

In short, decide your target device list BEFORE designing. And of course, design to suit all of them.

Access Barriers

Your customers may have a Smartphone but please find out if they have a data connection. Do not assume that all Smartphone users WILL have data connection. I do not have the latest stats but there was a time when 40% of BB users did not have a data connection – It is likely the case with several Android users now. They may have Wi Fi at home/office and might be happy using only that. If your app’s use case involves something other than home/office, you are in trouble.

Even among those who do have a data connection, people tend to also switch on/off data on need basis. If you want to do things in background, think about the possibility of data connectivity not being available always. Have a fall back mechanism through SMS or handle it well enough till data connectivity becomes available.

Depending on your user base, you will of course choose to have only USSD based access, only SMS based access or a combination of these, without needing data connectivity at all.

In short, do not assume access is there for all channels and have a fall back mechanism in place. Even if your app fails somewhere because there is no connectivity, do it gracefully. Keep user actions/data saved locally and sync back when you get connectivity.

Language Barriers

That English language literacy is pretty low is known. But most of us are clueless on what to do about those. Here are some pointers:

Where possible, make your complete app available in local languages. But this is easier said than done. When you do, ensure that the language is something that the man in the street understands it and not only puritan linguists understand.

Do not rely on local language support from the OS alone – Fonts may/may not exist. Test it out on majority the target devices and ensure all your screens/text render properly. If not, bundle fonts & rendering engines (like Reverie) as part of your app itself.

Even if your app exists in local language, the OS is still English (Sigh, how well things are in East Asia!) – so please ensure there is an easy way to reach your app. Educate users on your logo, how to place it on the home screen and so on.

Distribution Barriers

Not all devices have Google Play enabled. And not all users know to use Google Play. So please ensure your app is available from multiple stores, including your own web/WAP site. A shortened deep link should be made available that directly downloads the APK to the users’ phones. You could use this to share over SMS, Whatsapp etc.

Then comes the challenge of educating users about the “Security” settings to be enabled for non Google Play apps. I do not know of a fool proof way to do – Please look at Amazon Apps Store and Get Jar to find how they educate their users and you will get good pointers on how to educate the users.

Abnormal Scenarios

While the best case path of your interaction design might work well, how well your app reacts when it encounters an abnormal scenario is critical to its success. And the abnormal scenarios exist in plenty in our markets! Let me list out a few here:

  • Dual SIMs Which SIM is active and which is not. Your app may require data but the current active SIM may not have. Your app might rely on the user’s phone number for authentication (like Whatsapp) but that might not be the active SIM now. Add to this, the fact that users might actually remove a SIM and use only on specific circumstances. It might not be possible for your app to work in such scenarios but anticipate them and fail gracefully.
  • Data Usage The usage might jump from WiFi to 3G to 2G to no data network available. Your app should seamlessly work to ensure it works in all scenarios without bothering the user. Have fall back mechanisms to send data over SMS if no data network is available.. and so on!
  • SD Card People use their external memory cards in a variety of ways. Some carry multiple cards and keep replacing them as per the context – Family SD card with family videos, Personal SD card with personal videos (likely NSFW/NSFF videos!) etc. Your app should be able to detect that and inform the user that the SD card he used earlier is not seen now
  • Roaming (National & International) National roaming is an India only thing (which may go away too). People behave differently when they are on roaming and several voice/data plans they have too may work differently depending on home network or roaming. For example, a midnight free data pack might work only in home network and might be charged while roaming nationally. International roaming is more dangerous and the amount of bill shock it may produce is tremendous. So proactively find that the user is on a roaming network and inform him.
  • Browsers used Browsers like Opera Mini / UC Browser are very popular in our markets. They may/ may not reveal the exact user agent of the device. So when in doubt, ask the user through your interface instead of assuming things & doing something stupid.

So, that is our DALDA. “Device”, “Access”, “Language”, “Distribution” and “Abnormal Scenarios”.

[Karthik Srinivasan is senior manager with a telecommunications company.]

Comment (1)

  1. Could not agree more, particularly on the device, access, and distribution concerns.

    On an obliquely related note with respect to Android, as a general question to product developers/enthusiasts, while I do understand it isn’t a valid view per se, what is the general concern that prevents a progressive enhancement sticking to a base version that forms more than say 45-50% of devices and not go the other way around, which is avoided in general in the web?

    Yes, I have not done native android development much, but having worked with Cordova/Phonegap has only made this qualm more pronounced, thanks Webkit issues and fall backs.

Leave your thought here