Building a mobile team from ground up

I moved from Cleveland to Chicago about 4 months ago and I should say it has been pretty hectic but at the same time exciting. This time I am talking about my new gig at a travel booking company leading a mobile testing group.

I wanted to share my experiences building a team from ground up and establishing a stable process within 2 months. These are the approaches I took to create a stable test process and strategy.

Step 1- Gathering test devices 

As a new member to the team I had to start from somewhere. I decided to concentrate on what devices I have for testing as a start. As I was gathering the test devices I kept the below things in mind

  • What different devices do I have?
  • What OS versions do the devices have?
  • How better to manage these devices?

Asking the above questions help me to get my head around the test devices I had and I took this further and created a Wiki with all the devices I had, their UUID number, OS versions etc

Step 2- Creating a Test wiki to have central repository for testing resources

Another common problem in many teams is, resources are scattered all over the place. When I say resources I mean

  • Tools which are available
  • Username/Password to access different intranet websites
  • What are other accesses testers would need while doing their testing
  • Where to request access to these resources
  • Where is the information about different systems used by the company and team.
  • What are the available documentation on them

And so on……

To help in this, I created a team wiki where all the resources related to testing were housed in one page via links, tables, attachments and plain text. After the team found this useful I extended the Wiki to house all the information related to developers and testers in one place. This helped a lot and has since been used for all intensive purposes.

Step 3- Creating ET charters and doing time boxed testing sessions

I had to quickly not only establish a test process but also start doing testing. There were so many test plans which were previously used and outdated too. There were other test scripts which were in different locations.

I took the time to go through each one of them and see what can be re-used. Then, I created Exploratory Testing Charters some re-usable and some containing test ideas for different functionalities of our apps.

I did time boxed test sessions and recorded all my observations in charter. I housed all these charters in one central location so that it is visible to the whole team. In this way testing is not considered a separate/secretive activity and is more transparent and open to all.

Step 4- Creating a Bug template for consistent Bug reporting

Another thing I observed was all the team members including developers and business people posted bugs. But each one these reported bugs had different kinds of information. Some were descriptive, some had screenshots, some were just one liners about what they observed etc.

To bring consistency in the way anyone reports bugs in the team, I created a bug report template which consisted the following items-

  • One line description of the bug
  • Detailed description of the bug
  • Steps to Reproduce
  • The environment it was found in
  • The devices and OS versions
  • The app versions being tested
  • Screenshots.

All the other items like Priority, severity, who found it, who it is assigned to was handled by JIRA. So that made this job a lot easier.

Since I created the Bug Report Template the whole team has been doing consistent bug reporting and it is now readable by anyone.

These were my initial experiences after joining a new company. What was yours? Feel free to share them here.




Native App Testing Cheat Sheet – Quick Tour

A lot of people have asked me different techniques for testing Native Apps during my conference talks. Based on my experience and talking to different mobile experts in the industry I came up with my own testing cheat sheet which helps to do a Quick Tour on your native application. Hope you find it useful



A – App Lifecycle

E – End User Scenarios

L – Logs

  • Crash
  • Console

W – Wi-Fi/4g

B – Battery Life

U – User Reviews

C – Consistency

K – Keypads

C – Caching Problems

P – Performance

M – Memory

I – Interrupt testing

I – Installation testing

S – Storage

Native App Cheat Sheet MindMap








Quick Tour testing pneumonic – I/WE LACK UI PUBS

Effective communication for Testers

I recently wrote an article for Testing Circus on tester communication. It felt great to finally share my experience in communicating with different people from different race,religion and culture. If you did not get a chance to look into my article in the magazine here it is below.


We’ve all been there. Developers aren’t listening when you tell them the severity of the problem; you’re repeating the same status over and over to the same people; you accidently commit to a timeline or project that you can’t possibly complete. Communication is key.

This is the time where I will let you in on a truth that if you faced one of the above situations or something similar, you may be a tester who puts in lot of effort into your work but fail to communicate your ideas in an understandable and precise manner.

These are all common communication issues, shared by many software testers around the world. Now you may ask yourself – “Why is this a common occurrence among testers?” Let’s spend a moment to highlight some things which leads to this situation.

Testers often fail to realize that they talk to different audiences on a daily basis. They talk to project managers, business sponsors, developers, solution architects, domain architects, other testers, requirement analyst and so on…. The list is never ending. This being the case, are you going to give the same type of information to each and every person? Let me give you an example to give more clarity on this.

Say you bought an old house which needs lot of repairs to be done. You have repairs related to plumbing, landscaping, air conditioning, roofing, heating, kitchen remodeling, carpeting etc. (Yes, I know what you are thinking, selecting this house was a bad choice to start with!). Now, you call a plumber to your house – what type of conversation would you have with them? Would you talk about the problem with carpeting, heating, roofing and landscaping? Of course you wouldn’t. When you talk to a plumber you talk about problems related to water leakage, draining, and any other problems related to plumbing. Similarly, if you call a landscaper, you would talk about the lawn, grass, flowers, and decorative stones in the backyard and so on…. Although you have different repair work in your house, you talk about the specific repairs he/she cares about, not the whole picture every time.

This is the same case with testing too – it is important to know your audience when providing information.

For Example, Say you want to provide information about a critical show-stopper defect you found. The information you provide about the defects varies based on the audience:

  • The Developer would be interested to know what systems are getting affected due to the defect and any information related to other systems

  • The Business Analyst would be interested to know how this defect is going to affect the customer experience. He/she needs information related to the number of customers being affected and the impact to them.

  • The Project Manager would be interested to know how the show-stopper defect is going to affect project schedule. The project manager would have to make changes in the project schedule and estimates accordingly.

Thus, it is really important to pay attention to what type of information you give to what type of audience. So the first lesson here is KNOW YOUR AUDIENCE.

When providing information to your intended audience, make sure you prioritize your points. In the House owner example, if there is water leaking in the kitchen and is flooding throughout the house, this is probably the first information you want to communicate to the plumber instead of talking about replacing old shower heads with modern ones in your bathroom.

Similarly when providing information through status reports or bug reports, make sure you provide the top 3-4 points you want the stakeholders to know; this is what I call headlines. Just like how a news reporter first gives the top headlines of different things happening in the world to the viewers before getting into details, the tester gives the headlines on testing progress, about the top 3-4 items the stakeholder needs to know before expanding on each item. So, second lesson here is PRIORITIZE YOUR POINTS.

Often testers fail to realize that there is another important factor called communication patterns to consider when providing information. I classify communication pattern into 3 types.

Formal and Informal communication

Formal communication is when there is some sort of structure involved when providing information. This includes group meetings, business meetings and stand ups.

Informal communication is when there is no structure involved when providing information. For example, walking up to your developer and asking him to explain a feature in the system or walking up to your requirements analyst and asking her to provide more information about a particular story card. So there is no formal structure involved when getting/providing information

Face- to- Face communication

There is considerable amount of communication that testers have to do face-to-face with other people. When doing this they have to be aware of the following things to make sure he/she understands the information you are providing.

  • Body Language

I have had many situations where I was providing some information to the developer, while he is playing or texting on his phone; I’ve also seen situations where testers go on and on about a defect they found, thus leading the developer to get lost in information due to information overload.

The below points may help to be aware of your body language

  • Show interest in the discussion

  • Try to understand the full story before reacting

  • Be engaging

  • Maintain proper body posture

  • Maintain eye contact

  • Give clear, concise information

  • Facial Expression

Facial expressions tells you a lot about a person’s understanding. Are they just nodding their head since they want to get rid of the other person quickly, or do they have a blank look, meaning he/she doesn’t have any clue what you are talking about but are too proud to admit it.

Pay attention to facial expressions of your audience when communicating, as they will help to immediately show whether you are heading in the right path or digging yourself into a hole from which it will be hard to recover.

Social communication

It is really important to get to know your team members on a personal and professional level. You will be amazed by the power of social communication as it make a testers job so much more easier when you actually know a person, rather than just talking to him when you only need something.

Make sure you meet your colleagues outside work at restaurants and team events to get to know your team members on a personal level. Once you start doing this, the next time you are stuck with a problem or need help, people will be more than willing to help you out even though they may not be directly related to what work you are doing or the system you are testing. Kind words and simple expressions such has “How are you doing today?” “How did your kid’s birthday party go?” goes a long way in establishing rapport with your team members.


The fourth factor which hinders our job as information brokers (a tester’s task of providing valuable information about the system which would aid decision making) is not being able to understand cultural differences.

Have you ever worked with teams who are in different regions of the world and you have to remotely communicate with them? Have you ever been in a situation where you communicate something to the remote team and they provide you something which is totally unrelated to what you actually asked for? I was one such tester who was in this situation and it thought me a lot of things about working with teams in other regions of the world.

You think that you have no problems like the above? Here’s a simple exercise to prove my point. What is wrong with the below e-mail communication between an American manager (George) and Chinese Tester (Chang)?

Hi Chang,

Can you please make sure I get the status reports on January 31st?



The odds are George is never going to get the status report on January 31st. Why? This is the Chinese New Year which is a national holiday in China and many parts of the world. It is very important to recognize these cultural differences when communicating with remote teams.

Also, different words mean different things in different regions. Say, you are communicating with a remote team in India, it is important to understand that different words in India mean different things in the United States.

Words used in India

The US Equivalent





To intimate someone

To inform

It’s gone for a toss

Not working


Join venture

In queue

In line


Move forward

Passed out/to pass out


Again, no one is wrong in this case, it is just the way different regions use different words to mean different things. I have worked in both India and the United States and found this to be a real-life issue.

So, if you are working with a remote team, please put effort in an extra effort in trying to understand their culture and region. This will go a long way in building a good relationship with your remote team. So, the fourth lesson is UNDERSTANDING CULTURAL DIFFERENCES

Finally, we come to using Safety Language. Let’s start with an example-

Analyze the difference between the below sentences

It is going to rain today”

It might rain today”

Say you are using a weather app on your phone. It says “It is going to rain today”, so based on this information you prepare for rain, dress accordingly. When you come out of your house, you notice that is sunny, hot, and humid and there are no signs of rain. What would you think about the Weather app you used now? Will you trust it in the future? You may probably trust it once or twice and if it still gives you wrong information the odds are you uninstall the current weather app and install another competent weather app which can give you the right information.

What if the weather app had said “It might rain today?” or something like “Chances of rain is 30%” Then, you may have just taken an umbrella with you instead of going the whole nine yards of preparing for a rainy day. When you come out of your house it is still sunny, hot, and humid and there are no signs of rain. You may just say “Oh well! It is not raining now but I will just take my umbrella instead” and you will go your merry way. Once you get a slight drizzle of rain, you will feel happy that you brought your umbrella with you. Again, this is a very hypothetical example to highlight a point that the same is true for testers.

As a tester you are often caught by surprise and forced to commit to something which you have no idea about, you don’t have time to finish, or you are not sure whether you are the right person to do the task in the first place. How often have you been in a situation where your project manager puts you on the spot and makes you commit to something which you later repent that you should have never have done it. (Remember the manager from the movie “Office Space”)

During situations like this, you can use safety language to keep yourself from getting trapped. So try to use phrases like the ones shown below to have control of situations at all times.

  • It appears to be a picture of…”

  • It might fail under these circumstances”

  • It appears to fail”

  • You may be right”

  • I might disagree with that”

  • I’ve noticed that…”

  • My experience has been..”

So next time when someone asks you “In which scenario does the system fail?” you probably want to think twice and start your reply by saying “The system might fail under these circumstances……”

There you go, these are the 5 lessons I learnt which made me an effective communicator which is

  • Knowing your audience

  • Prioritizing your points

  • Recognizing communication patterns

  • Understanding cultural differences

  • Using Safety Language

If you have had similar kind of experiences, I would love to hear them. Please feel free to share them here or contact me with with your views


Our Software Testing World Cup 2014 story – The Four Musketeers

Our team “The Four Musketeers” recently participated in the STWC 2014 testing competition in the North America region and were Rank 5/36 teams. To start with, I should say our team had a blast and it was so much fun right from the way the competition was advertised, presented and conducted.

My team experiences of the competition can be divided and explained in the following phases-

Preparation phase-

About 3-4 days before the competition, my team members went through the information provided in the website and noted down important details which would be valuable to get more points. Also, we researched various free tools available which may help us in testing in terms of doing functional and performance testing.

It is interesting to note that, my team was so into preparing for this competition that one of my team members  cut short his vacation in Canada just to join the competition in person and help our team out. Now, that is true dedication!!!

The next thing our team did was discussing testing strategies and approaches we could use for the competition.  We started looking into various  books and testing courses we have taken (mainly BBST and RST) and got some ideas from them.

Next thing was resources. What type of OS’s and devices we would need to test the product. After a lot of discussion, we ended up having 2 versions of Windows OS (XP and 7), Mac OSX and bunch of mobile devices and tablets, along with a multi – plug to connect a number of devices all at once for charging and power.

Finally we came to the collaboration piece. How is our team going to collaborate and discuss things during the competition? A team member came up with the idea of using Google docs for collaboration so that each one can see the other persons updates as and when he/she is doing stuff.

Brainstorming phase

Once we saw the e-mail hinting that we will be testing an image and video capture tool, my team started brainstorming various possibilities and combinations in terms of whether the application would be a desktop app, mobile app or a web app.  For each type of app, what should be our test strategy?

It is funny that, 3 hours before the competition we though about various image and video capture tools and my team mate said Snag it is a possibility. But, my team dismissed that idea thinking that the product may be something in the beta version not yet available to the end users (Unfortunately we were wrong :-( )

2 hours before the competition, we started looking at different tools like Jing, Camtasia and other tools and started comparing the features to get an idea about how these kinds of tools work.

Execution phase-

Based on the previous phases, my team had decided various resources and testing techniques that could be used during the competition.

At 5:30 PM EST,  we uploaded a doc which contained the important factors that would help in getting better scores and some rules of the competition on google docs and shared it with our team. We made sure everyone could access it.

At 6:00 PM EST,  I joined the You tube channel and saw Matt and the Snag it representative (Stakeholder). I increased the volume on my side so that my entire team could hear the conversations. I was in charge of monitoring the online session and typing in the questions which me and my team members wanted to ask. We also simultaneously started downloading the builds to our respective devices.

While doing this, the other 3 people started noting down important points the stakeholder was talking about and which he cares about.

At 6:30 PM EST, we started doing a Risk analysis.  We identified different areas which the stakeholder cared about  and started thinking about potential risks for each of those areas. Then we thought about impact and the likelihood of some problem occurring in that module and came up with Risk Scores.

At 6:50 PM – We had quickly completed the Risk Analysis and started assigning the test areas within each one of us and prioritized our testing based on the scores.

At 7:00 PM – We started testing based on the risk score. We continuously were discussing and comparing results. Our testing approach was Risk Based Exploratory testing. We decided to spend about 20 minutes in each of the test areas identified and then moved on to the next one.

At 9:00 PM – Me and another team member started working on the “Test Report” while the other 2 continued testing and posting defects.

At 9:30 PM – We submitted everything and were really happy about our effort.


As I said in the beginning my team had a blast. The competition was pretty intense as there were some confusions and tension for the entire 3 hours. But at last we pulled through it successfully.

Some interesting things were the different testing approaches our team came up with like using some tools to check application performance, trying to test on mobile device in different ways, trying to interface with external applications through the app and I tried connecting the laptop to multiple screens like my TV and tried playing recorded videos of snag it to check video quality and performance.  And of course the beer and the pizzas we had throughout the competition helped too :-)

One thing which our team did not expect was that, the name of the product we were testing was released at about 5:45 PM, although the testing was supposed to start only at 6:30 PM. My team was unaware that we could start testing once we got the e-mail with the product download link and also, we thought we need to ask some questions to the business customer and test based on the high risk areas (We still stick to this that it was worth testing based on risks instead of randomly testing modules). So, by the time we posted the 1st defect there were already 60 entries in HP Agile Manager. Probably it could be a good idea next time, if there is information about when a team can start testing.

Overall this testing competition was worth it and my team will be competing next year and will try to improve on the limitations we had this time.



Apple and Android software updates – The real story

I have personally talked to so many people about Apple and Android software updates. Believe me, there were lot of discussions, arguments, debates about this but some things I consistently heard was

  • “Apple updates are so seamless and the user gets it immediately”
  • “Android updates take forever to reach my phone. I want the latest build now but my phone does not support it”
  • “It has been 4 months now and still haven’t got the Android Kit Kat update”

Now why is this? why can’t Android follow the pattern of Apple and give the updates to all the loyal android users out there, as soon as the updates come up? I have talked to so many people about this and have told them the reasons from my point of view in terms of comparing two different eco-systems and expecting them to act the same way although they are different on multiple counts. The differences come in many forms-

  • Apple is just one manufacturer and all its phones and tablets use the same operating system whereas Android has different manufacturers different phones like HTC, Samsung, LG, Motorola and so on….. Each one of them have there own separate skin on top of the android OS.
  • Each apple device has the same type of hardware and thus all the software updates work seamlessly with the device. As for android, the manufacturers use different chipsets, different hardware, firmware and have to make sure the android updates are compatible with these. In most cases it is not and thus the wait, the delay and inability for all android users to get the updates instantly.
  • There are millions of android phones out there and expecting the same software upgrade patterns on all phones is impossible!!!! It is like all users expecting everyone to get the same interest rate, for say there savings account throughout the world just because they have bank accounts. The point is there are different banks, there are different regions, different rules and regulations etc. (Not the greatest of analogies but I think it hits the point :-) )

This article below nailed my thoughts exactly and gave more detailed description than I did to my colleagues. It perfectly captures the real reasons why the software updates work so differently in the Apple and Android devices.

Check it out here -> Link

Have any thoughts on this? Share it here :-)

Finally realized the difference between Adaptive and Responsive web design

For the past couple of months, while I was talking to different people about mobile testing, they kept using the term “Adaptive web design” and “Responsive web design” interchangeably. Initially, I thought they were the same but became more and more curious about the terms when a colleague of mine indicated that there are some differences.

I did some research and found that, they are technically NOT the same (my colleague was right :-)). I realized that people do not know the actual difference between the two and are using it interchangeably.

So, what is the actual difference between the two you may ask? Here it is-

Responsive web design – In this, you make the page responsive to the width of a browser window. So, as and when you keep resizing the browser you will see the page changing dynamically and giving the user the optimum page view in different “Browser” widths.

Most of the stuff is done on the client side thus leading to some performance constraints

Adaptive web design – In this, you give the user different versions of the page based on the device being used. There is a device detection script which runs on a web server and each time a user access the website using a device, the script detects the type of device the user is using and loads up the page accordingly. It DOES NOT have anything to do with the browser width and it is related to the device screen size.

Since most of the stuff is done on the server side, there is less problems due to page performance.

Although, the above 2 approaches have different types of implementations they are similar in terms of its goal  i.e giving the optimum experience to the user in terms of the page being displayed when accessed via a phone, tablet, phablet or a desktop browser.

I used the below links to get a better idea about the similarities and differences

So there you go. Finally I found the answer to my question and hopefully this gives some clarity to people who have the same doubts about the 2 designs in their mind.

Next time, you see a person using these terms interchangeably, what would you say? :-)





Why Mobile Web Testing and how to become good at it?

A couple of years ago, I got into a totally new domain of testing and have never repented my decision since then. Yes. I am talking about Mobile Web Testing. Before, getting into mobile web testing and my experience, let me give you a broader idea about the Mobile ecosystem, how it is changing the world and why we need to be part of this revolution.

On a high level the mobile ecosystem consists of Native, Web and Hybrid applications (apps).  Each one has its own advantages and disadvantages.  Understanding the difference between them is the first step towards becoming a good tester in the mobile space. I personally have worked with all 3 types of apps and understood that there are multiple factors in each one of them. A tester needs to be aware of this and think about test objectives, test approach, test design and test execution specific to the type of app being tested.

A majority of my testing experience is in the mobile web domain where I researched various approaches, tools and networked with so many mobile testers inside and outside my company to get a grasp of the subject. As a result, I came to a conclusion that I still have to learn so many things due to the ever changing nature of the mobile web domain and the mobile space as a whole.

Currently, the direction everyone is going towards is “Responsive Web design”. If you haven’t heard about this term, please stop reading any further and at least read the first paragraph of this link ->  It is going to be almost mandatory for testers to know about this, as the world is heading in this direction and it is here to stay at least for the next couple of years or so. Examples of Responsive web sites are Microsoft, Disney, Boston Globe and there are others here at

Testing these responsive websites is a challenge as there are different devices, different form factors, different screen resolutions, different browsers and numerous other permutations. This being the case, I tried out different approaches that will help me become a better tester. Some of them are as follows-

  • Networking with inside/outside mobile testers and consultants.
  • Keeping updated with the latest in mobile technology.
  • Researching different tools to help out in testing
  • Trying to see how Rapid Software Testing approaches could help out in mobile testing.
  • Researching production defects. This is to help to focus testing on types of problems the users are seeing in the application.
  • Attending mobile focused conferences

So, from all the above description, you should have started to get an idea about the message I want to convey through this article. Still thinking!!! The answer is “Thinking out of the box”. Mobile being such a vast domain governed by multiple factors, it becomes all the more important to try out different approaches rather than just sticking to a set of scripted test cases and hoping you have the so called “100% Coverage”. These test cases are written usually by an individual who thinks he/she knows all the things affecting a particular module but the truth is “They Don’t” and for that matter no one does until a new feature is fully implemented, especially in the mobile web space.

I have seen this happen time and again throughout my experience as a mobile tester. So please do not fall into this trap of writing test cases for each and every thing. By doing this, you will end up consuming valuable testing time that could have actually been spent on exploring the application. The mantra I follow is “Very High level test cases complemented with Exploratory testing”.  Again, this worked for me on a real industry application which is used by millions of users in the US but is not a hard and fast rule. See which works best for your project but avoid pitfalls of completely relying on scripted test cases.

Finally, never hesitate to challenge anything when working in a mobile web project. “Always ask Questions”. The ugly truth is no one has any idea about how a new feature is going to implemented in responsive web design world (even if you have mockups). There are always challenges and the least you could do is, challenge ideas and question idealistic thinking which in turn would help to flush out ambiguities in requirements.

So join the mobile revolution and lets become good mobile testers!!!.

How to save battery life on mobile phones? – My thoughts

Recently, a colleague of mine asked me a question, “How to ensure the mobile apps do not consume too much battery life?” I thought this was an interesting question as I have always faced problems with battery, due to my insane usage patterns :-).

That being said, below were the steps I have taken which have helped me conserve battery life on my iPhone (This holds good for android phones too) and helps me give a feeling of control over the apps I have installed and my phone as a whole.

Here goes-

In general a mobile app will use too much battery life when-

 1. It uses location services like Facebook, FourSquare, .  What happens here is the app continuously keeps updating the current location of the user periodically, in certain time intervals and it drains lot of battery life.  Same holds good for actual GPS apps like Apple, google maps, mapquest etc.
You can disable this by going to Privacy -> Locations Services on your iPhone and there is something similar to this on android phones. This will force the application to get the user consent before figuring out the GPS coordinates.


2. If the app uses lot of images/animation and if it is constantly running in the background, the battery life drains.
For this, make sure you kill the application after you use it by double clicking on the “center button”  located at the bottom of your iphone and manually close that app.


3. Music related apps drains a lot of battery. Spotify, Pandora, iTunes. Same applies to Video players, Podcasts too.
Same as above


4. Screen brightness is one more thing which drains battery life.
The optimum way to fix this is go to Brightness & Wallpaper -> Select auto-Brightness for optimum battery life.


5. “Notifications” is one more thing to keep in mind. This is not a problem if you are using 5-6 apps. But, when you have 45 apps like me on your phone :-), then you have a problem.
you may want to control the Auto push notifications from different apps by going to Settings -> notifications.
Here you can individually control each apps notification mechanism.


6. “Browsing” is one more thing which obviously drains battery. From reading the news via BBC, Flipboard to reading books, articles etc all amounts to draining of battery life. This sometimes is unavoidable.


7. Recording Videos and playing the will of course affect battery life.


These are all the possible things I can think of right now which affects battery life, hope this helps in answering this question. If you have any other tips please feel free to share it here as it would be helpful to me and other readers.


Thanks all!!! Happy Testing!!!

HTML5 vs Native – The hot contenders for total web domination and the great mobile debate

Over the past 6 months,I have heard so many conversations  about HTML5 being slow, bad, has  no future and people should not consider it. Some may be true and some are totally false. Let’s analyze this further in the below sections-

We know Facebook and LinkedIn changed their applications from HTML5 to Native (I personally liked the LinkedIn HTML5 app). You can refer to their reasons of why they changed in the links below.

The reasons mentioned in the above links were very valid due to nature of the business Facebook and LinkedIn has with its customers. They were having problems with-

1) Performance issues – Running out of memory

2) Smoothness of animations

 3) Getting detailed information when things go wrong in production

All this was because both had millions of customers using and interacting with their app on a daily basis. The load/traffic was so heavy and performance was a major concern.

Just because these 2 companies dumped HTML5 and went native does not mean HTML 5 is dead because again

  • The nature of the business
  • The type of customers the app attracts
  • speed  to  market

are 3 VERY major things to consider before deciding on going the HTML5 or the Native way.

For example –

Let’s take a restaurant app. The sole aim of this app is just to show the different menu options they have. They don’t have any moving pictures or animations but have just static pictures of food. They also have their location displayed via Google maps API.  If a customer wants to order something, he clicks on the phone number link, which immediately loads the phone number on your phone and you can call them.

With this being the case, they could go the HTML5/Hybrid approach and get this app to the market quickly. They don’t need to create 2 native apps one for iPhone and Android as it could be costly to them. Also, the people who use the app may be a fraction of that of Facebook and LinkedIn. Probably only users who know about the restaurant bother to download the app and look into it.

Similarly, let’s take an insurance app. Do insurance apps have customers like Facebook and LinkedIn? NO. People who have GEICO, State Farm, and Progressive etc. interact with only the specific app based on their insurance type. In these cases, HTML5/Hybrid approach could work for them.

Like this there are many examples where probably going Native would be time consuming (for whatever reason), costly and not well suited to the type of business.

Firefox OS

We talked about apps, now coming to OS. People are bashing the new Firefox OS and so many people told me that it is waste of energy and time. But, do they know that, their initial sales of their phones went out of stock within a few hours (again you can argue with me that they may have put up only small number of phones compared to Samsung and Apple for sale, but still this is better than not any phone getting sold at all). Check this link out

At least based on the specs, the 2 phones Keon and Peak have relatively decent specs compared to other phones in the market currently. Also, since this is a developer version, it gives more flexibility to play with your phone and make it work as you want it.

In fact T-Mobile, Sprint and other carriers/partners have already decided to release phones with Firefox OS. Check out the list of partners here


So, to summarize, don’t write off anything as useless especially technology. If we do, then we are the most ignorant people on earth as we have seen time and again, how disruptive technology/companies like Dropbox, Samsung Galaxy line of phones, Instagram gave other people the run for their money (Literally!!!!).

I just wanted to write about this, to get these thoughts out of my mind. Let me know what you think about this or have any feedback.

Mobile, tablets, browser technology trends – 1st Quarter 2013 – Wrap up

There were so many people who talked to me about different technology trends happening in the mobile, tablets and browser space. Since, I generally keep track of these things, I thought I should highlight hot topics in technology happening each quarter in one blog post.

So, I decided to start with this blog post to give all the technology news which happened this quarter. I will try to give updates like this for the succeeding quarters in different blog posts.

Here goes…

Browsers- Firefox and Opera




  • This is going to decide the fate of Blackberry (In fact they change their name from RIM to Blackberry). They are really serious about this
  • Full touch phone
  • Buttons on the side of the phone
  • Has 2 ports – micro USB and micro HDMI connections
  • BB10 OS
  • Blackberry Hub feature, like the control panel of your computer
  • Releasing today with AT&T at $199 with contract. Will release in other operators in the next upcoming weeks.
  • Blackberry planning to update their Android emulator to run Jelly Bean apps
  • You can port Android 4.0+ apps to BB10 platform.

Phone Specs (HTC One, Blackberry Z10, iPhone5, Nokia Lumia 920)

Apple iOS updates

  • iOS 6.1
    • adds Long Term Evolution (LTE) support to 36 additional iPhone carriers worldwide—or now 56 total.
    • ability to use Siri to purchase movie tickets in the U.S through Fandango
    • iTunes subscribers can download individual songs to their iOS devices from iCloud.


  • With just a few quick steps, it’s easy to open the phone app on any locked iPhone running iOS 6.1.
  • the process involves holding down the power button and aborting an emergency call.
  • iOS 6.1.1
    • This update fixes an issue that could impact cellular performance and reliability for iPhone 4S.
  • iOS 6.1.2
    • Fixes an Exchange calendar bug that could result in increased network activity and reduced battery life

iPhone5S and iPhone Mini rumours


  • Security Enhancements in Android 4.2.2
    • It includes a feature with which your users will be able to verify applications prior to installation thereby preventing harmful apps from entering the mobile device.
  • enables you to configure VPN in such a way that it will not have access to the network until a VPN connection is established
  • Ubuntu phone
    • Canonical – company
    •  The Touch Developer Preview can run on Nexus 7 and Nexus 10 tablets, as well as the Galaxy Nexus and Nexus 4 smartphones – Developer version

 Interesting Problems

  • new bug has been found on the Galaxy S III that can let users bypass the lockscreen and access all phone functions


  • Apple announced the 128GB iPad
  • its stainless steel frame and soft-touch back that’s available in gray or red. The device measures .42 inches thick (about the same as the Kindle Fire HD‘s .41 inches) and weighs 13.05 ounces, making this tablet lighter than the Fire (13.9 ounces) but heavier than the Nexus 7 (12 ounces).
  • Biggest advantage is – The Slate 7 has a microSD card slot and microUSB port.
  • 1024 x 600-pixel – resolution lower than kindle and nexus 7

Other Technology news

  • Nationwide launched their insurance app
  • Samsung Wallet App – exact copy of Passbook