Month: January 2014

Fix For Call Volume Bug In Moto G

The Moto G has been a fantastic phone so far, except for one small bug which becomes a big irritant. If the phone is used with a headset (wired or bluetooth) and you take it off, the call volume will drop to really low levels, making it hard to hear what is being said on the other side. A reboot usually fixes the problem, but that is not an ideal solution.
The other, simpler, fix is to reduce the volume while in call and then max it. What usually happens in a situation like this is that the user will only try to push the volume to the maximum (which the phone usually is at) than reduce it. To make the fix work, you have to first reduce the volume and then increase it, making it very likely that this is a software issue than a hardware one.
Update: Motorola has released an OTA update for the single SIM GSM version for this with the 174.44.1 update that fixes this bug. There is no word on when it will be rolled out to the other models.

Filed under: AndroidTagged with:

Lifestyle As A Luxury

As you can see, the title is an obvious play on ‘Luxury Lifestyle’. After five-years of working on my own, what I have come to realize is that I have a lifestyle that is considered luxurious, mostly by people who work a regular job. Luxury, in this context, is not being able to afford a fancy dinner every evening, but the ability to go for a walk or a run in the evening when the streets are starting to fill up with the evening rush hour traffic. It is the ability to take half the day off, on a weekday, to have a nice lunch by yourself out in the winter sun, or catch a movie all on your own.
Like other luxuries, this one also does not come for free. I have had to give up having what most would call a regular life — owning a home, family with kids etc. — to support this lifestyle. To be fair, it is not an exact correlation or causation, as there are other factors too that have played a part. I did struggle through most parts of the five-years on my own, trying to bridge the gap between what I don’t have and what everyone else seemed to have, only to realize recently that it is a gap that remained unfilled not for a lack of ability, but for a lack of willingness to fill it.
Like other luxuries, as long as it delivers contentment for you and if it feels right, the price is always right. I, for one, find it hard to own something extremely expensive. I’m one of those people who merely don’t own things, they are owned by the things they own. Thus, even the thought of owning a luxury car (not that I could probably ever afford one) is an unsettling one for me. I would probably love to rent one some day and experience it for a short period of time, but not own one. For someone who loves owning one, doing exactly that is the way to go forward. You don’t owe an explanation or justification to anyone for what makes you truly happy.
That said, luck is a significant part of being able to live this lifestyle, unless you are someone who is extremely good with their financial planning. I am not one of those people. This is partly because of one of the bizarre outcomes of subsisting on very little money when I moved to Delhi. When a time came where I had more than what I needed, it really didn’t get me much joy, especially as I tried to buy my way into respect, consideration and love. Money, for me, is something that is necessary to have at a basic level. It is nearly impossible to live without it, or live without someone who has enough of it to take care of you.
But, I digress.
You need a good share of luck as being unwell or getting into a serious accident can dent seriously even substantial bank accounts. No matter how careful you are, or how gifted you are, the fact is that you cannot control most of what happens to you. If it does go wrong badly, a lifestyle like mine won’t be possible. The corollary is that even the most accounted-for and provided-for existence cannot account for or provide for all eventualities. Should there happen a massive global market crash, odds are that me, a newly minted millionaire and the beggar on the road are all going to be on the same boat pushing up the river of survival.

Filed under: Misc

Building A Digital Product: Part I

There used to be a time when building and launching a digital product was a straight forward affair. The steps were something like this:

  1. Start with a rough idea of what you were looking for
  2. Find someone who could design and build it for you
  3. Find people who would help you run it and go live.
  4. Find ways to market the product.
  5. Find ways to sell the product.

Other than the really big players, most of the regular Joes would handle most of the steps on their own or, in some extreme cases, handle all the steps on their own.
In the last five to eight years the steps have been shred to bits, thrown out to the dustbin and replaced with a set of steps that bear no resemblance to the earlier ones.
Most of this disruption can squarely be blamed on mobile computing. The revolution that started with telephonic devices being able to access bits of textual data (read SMS), was turned on its head when the same devices were transformed into data devices that could also do telephony as one of the many things it could do.
The other significant development that has caused the playbook to be thrown out is the commoditization of many of the moving parts that are used to build a digital product. From databases, to job queues, to logging, to any other part of the technical stack, finds an array of plug-and-play software service platforms that a new product can leverage from day one.
In the early days, teams had to develop everything — from email subscription systems, to delivery systems to, logging infrastructure — to get going. With all these new services, product builders are less builders and more integrators these days.
While this has created an entirely new universe of opportunities and possibilities, it is also responsible for creating a lot of confusion for companies and individuals looking to build products.
What this series will attempt to do, in the first part, is to bring some structure to the steps and elaborate on the steps a bit with an aim to reducing the amount of confusion in the market regarding the steps.
I have no illusions that this will be a definitive list as there are parts of the stack and ecosystem I am completely unaware of. My idea is to fill in the gaps that I can and I’ll be more than happy to bring in suggestions about what else can I cover here.
I am going to tackle the more technical aspects in this post:
Design: Designs are best approached first with storyboards. The story boards are used to create process flows. The process flows lead to wireframes. The wireframes lead to the final design.
You can skip all of the steps and go directly to a design, but the odds are that you will struggle at a later stage to force fit that disciplined a process into an existing system that has grown without it.
What is more important — short term gain or long term pain — make your pick.
Development: The choice of framework/language to build on is made at this stage. Unless you are someone who knows technology very closely, avoid using the latest fancy framework in town.
You have to establish coding standards, documentation standards, bug tracking, version control systems and release management processes.
Testing: Set up both automated and manual tests to address both logic and real-world usage. Testing infrastructure built right will include a good set of unit and behavioural tests and a continuous integration framework that will catch most errors during the build phase itself.
Deployment: No (S)FTP. Simple. Deployment options are available these days from the simple, to the ridiculously complicated. It gets harder when you have to update code on a pool of application servers that need a rolling update/restart cycle.
The more challenging part in this is to abstract away this part of the stack to a simple interface that the developers can use. You cannot and should not expect developers to debug problems in the deployment infrastructure.
Distribution: A local CDN or an international one — which is the right one to use? Should I use a CDN at all? Recently, a company that I spoke to had a response time to their origin server that was 1/5th of what they were getting from their CDN. This was done to leverage cheaper CDN bandwidth and is a classic case of cost optimization at the wrong place.
Is Couldfront the right solution? Can my preferred CDN provider handle wildcard SSL termination at reasonable cost? How costly is it to do a cache purge across all geographies. Is it even possible? Is it important to purge CDN caches? Is a purge important to avoid compliance hurdles for some obscure requirement in my market of choice?
Mobile-specific Parts: Native, cross-platform or HTML5? Do I need a mobile application at all? Which platforms should I target? What is the minimum OS level that I should support on each of those platforms? How do I align those decisions with the target audience I am going to address?
Outbound, non-consumer-facing Services: Should I expose any of my internal data with a developer-facing API? What should I use to expose that API? Do I build it own on my own or do I use a hosted platform like Apigee? What sort of authentication should I use? What sort of identity management should I use. Should I even try to split identity and authentication as two different services?
Inbound, non-consumer-facing Services: What do I use to handle data that I fetch from other sources? How do I ensure that I cache my requests to respect rate limits. What is a Webhook? How do I go about implementing one?
Replication & Redundancy: What is the maximum acceptable downtime for my application? Is there a business case for a multi-DC deployment? How extensive does my disaster recovery plan have to be?
AWS, Rackspace, good old dedicated rack in a datacenter? Should I use Glacier? What should I use for DNS management?
Analytics & Instrumentation: DAU, MAU, WAU — what all do I have to track? Are bounces more important than acquisition? Is¬†acquisition more important than repeat transactions? How do I bucket and segment my users?
How do I measure passive actions? Should I start tracking a minor version of an otherwise less-used browser as my javascript error tracking reports are showing that the current release is breaking critical parts for my most valuable demographic who use that exact obscure browser?
Wait, I can track client side javascript errors?
Conclusion
As you can see, the list raises more questions and provides no answers. This is intentional as there is no one-size-fits-all answer for these questions. Even within specific company lifecycle segments (early stage, stable start-up, established company), the internal circumstances vary from company to company.
These list is more a starting point than a destination in itself. Use it to build a better framework that is suited for your organization and your product. And if you need more help, just ask!

Filed under: Start-ups, Technology

Moto G Review

Having now spent close to a month using the Moto G, I can now sum up the device in one word — fabulous. The device has not been officially launched in India. I was fortunate to have been gifted one by someone living the US and it cost the regular $199 retail there. If they manage to price it under Rs 12,000 (and closer to Rs. 10,000) in India, Motorola could have a winner on its hands.
DSC_0543What I like about the device:

  1. Battery life: I use location services during a major part of the day, which, previously, was a huge drain on Android devices. I am easily getting 24+ hours on a full charge and have never used the battery saver feature.
  2. Android Kitkat: The slight lag (more like a stutter than lag) that used to be there on even the high-end Android devices is gone. Even with 1GB RAM, the transitions are buttery smooth and comparable to iOS.
  3. Nearly-Stock Android: There are a couple of Moto-specific apps in there, but nothing that gets in your way. Rest is pure Android all the way.
  4. Price: You can pick up at least three of these babies at a price that is lesser than a Samsung S4 or an iPhone 5C.
  5. Main camera is pretty decent. Just remember not to shoot with it in low light.

What I don’t like:

  1. No external SD card support. I don’t store much media or click a zillion pics, but I’m already down to 9 GB left on the device.
  2. 1 GB of RAM.
  3. There’s a bug (not sure whether it is software or hardware) that can cause call volume to drop after using a wired or bluetooth headset. Can be fixed with a reboot, but annoying all the same.
  4. USB port is at the bottom of the phone. Never liked that positioning. It is a personal preference, though.

DSC_0552While I really like the device, you do need to keep in mind that I don’t fit the profile of the average smartphone user for the following reasons:

  1. Limited apps usage: I don’t use Facebook, Twitter, G+ and most other social networking apps. I do use Whatsapp and BBM, but they don’t seem to eat up as much battery and processing as the first three.
  2. I don’t game at all on the device. There’s a chess app that I keep for the odd rainy day, but have not used it more than twice or thrice in the past year.
  3. I don’t watch much video on the device other than the odd YouTube clip.
  4. Reading has moved completely to a 7-inch Lava tablet.
  5. My data connection is permanently set to EDGE. I don’t use 3G.

Before I picked up the Moto G, I was using the Micromax A116, which has been a pleasant experience. After using it for almost a year, I’d rooted it and switched to ROM that had thrown away a lot of the unnecessary bits and made it nearly stock Android. Even that phone was giving me a good 24-hours of usage on a single charge. The reason why I wanted to try something else was that the build quality is extremely poor and I doubt it will be able to take another year or two of abuse. There are also little niggles like the problematic GPS lock, lack of a compass and issues with the filesystem at times.
DSC_0548The Moto is my first Google Android phone, which is a route that I have been looking to go down for a while now. The migration assistant provided by Motorola (works over Bluetooth) is quite good and I could switch devices (with data and apps) in a couple of hours. The device does only MTP, so it cannot be mounted as a regular volume on computers. Since I’m on Linux, I use gMTP, which can misbehave a bit at times. The fallback is Bluetooth, which is the disagreeable option when it comes to speed.
Overall, Kitkat seems to have improved how Android handles the idle state. This has resulted in better battery life, for me at least. There are rooting guides and ROMs available for the interested parties, as usual, on XDA, but I’m pretty happy with the way the device is right now. So I don’t see rooting and custom ROMs happening anytime soon. I like my devices to function flawlessly and stay out of the way and the G increasingly looks like a good candidate for that. I’m well past my weekly flashing phase on my phones and a lack of excitement is a welcome change on that front.

Filed under: Android, MobileTagged with: