The Heisenberg Uncertainty Principle states that as you observe the world, you also disturb the world, which can affect your observations.  So what on earth do mobile analytics have to do with Heisenberg?

Did you realize that excessive analytic capture can HURT your business?

Recently, I was approached by a popular game provider. They were having trouble figuring out why their apps were running slowly, and their analytics were showing that this latency was causing customers to stop playing.  We did an investigation, and discovered that the application was logging every touch to the screen.  This required a network connection to be established, and data transferred to the analytics server before the game could continue.  In other words, the observations/analytics were affecting the world/gameplay too much, and was actually HURTING the developer because users were getting annoyed and stopping their play. Heisenberg in action.

In this case, the developer re-vamped their observations. They still gather all the data, but It is not reported to the servers individually.  By creating an analytics queue that is reported to the server every x minutes, the developer VASTLY reduced the latency in the application. As a result, their users kept playing longer and returned to the game more often.

In conclusion, analytics provide you with great power.  But as Uncle Ben told a young Peter Parker “With great power comes great responsibility.” You must make sure that your usage of analytics does not actually hurt your applications and your customers.

Have you experienced applications where excessive data capture has discouraged you from using them? Is it possible that analytics are holding the success of your business applications back?

Many mobile websites have a separate url (e.g., m.myawesomecompany.com) with a limited scope compared to the PC website.  Is this the first impression you really want to make?  If you advertise your website in a public place (or even on TV), people are going to tap it into their phone.

Mobile first responsive web design (RWD) is the idea that the same webpage and content can be viewed on any size screen.  Obviously, the site needs to provide the information differently on a phone vs. a tablet vs. a PC vs. a TV, but this can all be taken care of in the code.  Start by designing WHAT you want to tell people, and then build in your HTML and CSS the code to deliver it to different platforms.

Did you know that NetworkExchange Blog uses RWD?  You can see how RWD works by simply resizing your browser (yes – right now!)  Here is what the homepage looks like:

We start off with 3 columns of posts (at the bottom). As I shrink the window to “tablet size”:

Note: now there are just 2 columns of content (vs.3) Notice that all of the images are resized to fit the screen (happy guy in car, I am looking at you!). There is no loss of content for our readers on tablets.  Let’s keep shrinking to smartphone size:

Now we are down to one column. WE did lose the banner ad (happy guy in the car), but for the most part, that will not be missed by smartphone users, and the site will load faster for these users.

Looks cool, right? This is the experience your customers are expecting on mobile.  Give them everything – no matter the device.  There are performance issues to be had with RWD. You need to make sure that your homepage is simple. BostonGlobe.com is another great example of RWD. While BostonGlobe.com looks great, there are a lot of files, and it uses 1.5MB of data. This takes TIME to download on a mobile device, so you must make sure to include performance as a metric of your RWD.

Is your company website mobile-ready? Could RWD help you make the leap efficiently and effectively?

Mobile browsing will soon eclipse traditional web browsing, so performance is something to think about NOW, not later.  Mobile users are often just checking out your app when they have a second in the checkout line, or at a red light.  Since SPEED is even more crucial in mobile, it follows that it is a requirement for app success, customer satisfaction and sales.

Ok, so faster apps will keep customers engaged, encourage purchasing, and draw them back to your site, while also reducing costs (less server usage).   Sounds like a win/win for your company. Are you ready to get started?

The Application Resource Optimizer (ARO) is a diagnostic tool that monitors how your mobile application uses the mobile network –which when used inefficiently can be a major performance issue.  By testing your application with ARO, you will be shown issues that are usually simple to resolve and will provide you with large performance improvements.   Over the last few years, I have tested hundreds of apps, and over 98% had potential to become faster. Odds are, so does your app.

In recent blog posts, I have discussed how caching can speed up your mobile app.

What are you doing to shore up the speed and performance of your applications? Share your experience in comments.

Today, I’d like to tell you about another reason to use ARO. This one will not speed up your app, but MAY save you from an embarrassing security incident.  When issues with improper data usage arise in the press, it is generally not good news for the application owner.  Are you handling your customers’ data properly?

I’ll show you two examples of applications where ARO found major security lapses in the data being transmitted:

1. You’ve got (my) E-mail

Sending sensitive information like passwords in the clear.  Sensitive customer information should NEVER be sent without encryption.  However, Here is a screen shot of data that I took in a recent network trace:

Look at the first line. Yes, this is my e-mail address (LOGIN) and my password (inside the quotes).  Yowzers! What if this account had all of my personal details in it?  Luckily, this is a test account with more spam in it than the canned meat aisle at the grocery store.  All it takes is one bad guy intercepting this data to wreak havoc on your customer.  Obviously, this is not a good idea, and should be avoided.

2. You take the high road, and I’ll take the low road

I was speaking to a developer who mentioned that I would not be able to see any of their data, since it is all sent in a secure https websocket.  We ran the test anyway. What I discovered was that the data that was supposed to be secure was being sent under regular http without any encryption!  Both connections ended in the same place (the encrypted road, and the unencrypted road), but the data was taking a different route than expected.   Luckily, this app was not transmitting banking data of customers, but the developers were still surprised by my findings.

Here is a screen shot from the ARO tool for scenario #2.  In this case, the websocket packets are colored in green, and the file that is SUPPOSED to be in that websocket is in gray.  Companies who deal with sensitive information should utilize ARO (or other tools like ARO) to ensure that they are not jeopardizing their customers’ data.

Running your app through ARO is a simple test, and you owe it to your customers to make sure that the data you are using is being transmitted securely.

What resources are you using to track and ensure the security of your apps?

Of course, it is important that you think out how location adds benefit for your customers. Once you’ve done that, the next step is to figure out how best to implement location in your app. The Application Resource Optimizer from AT&T is a tool that helps developers speed up their application and reduce the network impact of their applications.  As the outreach lead, I have worked with over 200 top mobile developers to optimize their apps.  While looking at the traces of these apps, I have noticed an interesting trend in HOW mobile app location is being used.

Nearly every application I have tested uses the default Latitude/Longitude of 0°/0°.  For those geographically challenged, this is a location in the Atlantic Ocean about 380 miles south of Ghana and 670 miles west of Gabon:

While this location may not have a good Vietnamese restaurant or decent latte nearby, many apps actually start downloading maps with this default location. My favorite initial download looks like this:

In building a mobile app, getting useful information to your customers should be your #1 priority. Is this the first bit of data you want to provide?  If not, I have a couple of suggestions:

1. Get a rough network location while the GPS is triangulating. A map of the nearby zip code is better than the Central Atlantic.

2. Wait a couple seconds for a rough GPS location. Better to wait a second and provide value than to immediately start downloading useless data.

3. Pick a cool initial location.  Maybe the city where you are headquartered, or the location of your first store, or perhaps a map of a school shaped like the Millennium Falcon.  If you can bring a smile to your customer’s face, they are more likely to put up with the short delay.

Can your high school make the Kessel Run in under 12 parsecs?

Why cache?  Well, caching data locally allows content to get to the end user faster.  It reduces the amount of data your app uses and reduces the battery drain of your application. Caching data is a simple way to speed up your app and save battery life. Further, since you are paying for servers and the bandwidth that the servers are sending down to your mobile application – you’ll even save money.  This performance improvement is an all-around winner!

What are you waiting for?

There are two common headers used for caching, and each behaves differently: Cache Control and ETag. I’ll do a quick description of how they work and then conclude with the preferred caching for mobile.

Cache-Control gives the age until the file is expired (in seconds).  For example, this file will expire in 1.43M seconds (about 16 weeks).  Every time a file is needed, the application looks for the file in the cache first.  If the file is there (and is not expired), then it is served immediately (this takes about 50-250ms in my testing). If the file is expired, it is re-validated on the server and either downloaded or served from the cache.  If the file is not present in the cache, the file is downloaded from the server.  In my test of a 105K file, loading from the cache took under 500ms, and loading from the server took 2-5 seconds. Cache loading in this case is 75-99% faster than download.  This performance improvement is one your customers will notice.

ETag: Each file has a unique ETag ID header.  When the file is to be served, the application first checks the existing ETag against the server to see if the files are identical.  If they are identical, a 304 Not-Modified response is sent.  If the file is changed, the new file is downloaded to the device. Note that ETags vary by server, so if you have a distributed server, you should not use them.

In this example, the application has the file in cache, but first uses a HEAD request to just get the ETag header to compare to the cache. Since the request is just for the header, the file is not downloaded.

This request took about 2 seconds to create the connection, get the request, and then process the image from the cache.  Since just reading the file takes 2-5 seconds, using an ETag is 0-60% faster than no cache at all.

So which is better?

Since Cache-Control cache retrieval does not need a network connection for validation, it is much faster than using ETags.  In the two examples above, loading an image from the cache with Cache Control takes under 221ms, and 2-3s when using ETags.

Performance research shows that HTTP requests had the biggest impact on reducing response time.  Based on this, they recommend that to reduce latency (for the Web), removing ETags is a good way to speed your applications.  If removing ETags speeds up applications on the Web, this speedup will be only accentuated on mobile.

In conclusion, any caching is better than no caching.  However, to take advantage of the speed and power savings that caching can provide, take advantage of cache control.

Come visit me at the AT&T Developer Summit in Las Vegas on January 7th at 3PM PST. I’ll be presenting a talk called, ” Turbocharge Your Mobile App,” where I can help you evaluate your caching success!

Have you tested your application to ensure that caching is correctly implemented?  Try AT&T’s Application Resource Optimizer to see if your application is caching correctly.

When setting up email sync on mobile devices, users are often given options on push vs. poll, and options to change the timing for polling.  Since having the phone check for  email too often will kill your battery, what is the optimal setting to balance e-mail delivery and battery life?

Push vs. Poll – What’s Best for You?

Let’s start off with describing what we are talking about: push email is delivering each mail to the device as it arrives, while polling email is when your device makes regular checks to the email server for new messages (polling the server).

When I began thinking about push vs. poll, I assumed that push was always the best option.  However, as I began working through the way that connections are made, I began to realize that setting up a device to poll less often will significantly reduce the battery drain on my device and potentially improve my concentration and productivity.

Do the Math

Ok, now to walk through the data. (My assumptions and sample calculations are at the end of this post.)  If you get 25 emails per hour, email push costs 250J of energy, and polling costs between 30 and 600J/hour:

Five-minute polling uses 87 percent less energy, and 10-minute polling uses  >200 percent  less energy.

The break-even point for five-minute polling is 12 emails per hour, and for ten-minute polling, it’s 7 emails per hour.

What does all of this add up to? If you get fewer than seven emails per hour, push is the most efficient way to get your email.

Here is the kicker!  It is actually better for your battery to get email in real-time in evenings and on the weekend (when your e-mail load is hopefully lighter), and to poll at regular intervals during working hours.  I would hazard to guess that most professionals actually are doing the opposite, and their mobile batter life is suffering as a consequence.

Give it a shot, and tell me what you find out!

Doug has been a lead technical member of the AT&T Developer Program for nearly ten years, starting with helping developers learn mobile Web development from WAP to html to HTML5. He has also worked on messaging and video streaming applications.  Prior to his time at AT&T, Doug received a Ph.D. in inorganic chemistry at the University of Wisconsin-Madison where he built applications and studied how to measure and optimize the formation of polymers. He received his B.A. at the College of Wooster in Mathematics and Chemistry.

In his spare time, Doug enjoys being outside, hiking or biking with his kids, traveling, and knitting.  He does not really enjoy cleaning up after his dogs, bunnies, and chickens (but he does like the eggs!), and is nervous about the familial rumblings about adding alpacas to the herd.

As a work-from-home father of three small children, Doug plans not only to blog about mobile optimization and performance, but also about the challenges of being productive while working remotely.