Search Engine Optimization

Google, Bing and Yahoo all have different search bots for mobile. Google’s recommendations on how to make sites mobile friendly are all based around building separate sites and then ensuring that the Google mobile bot is redirected to the mobile version. Matt Cutts has talked about this in a video answer and Google has gone so far as to describe how you should redirect the Google mobile bot in some detail.

What does this mean for sites using responsive web design? Honestly, I don’t know. Nor does anyone else it appears. There is some question about whether or not mobile SEO is even worth pursuing.

But it is worrisome. Google recently announced that mobile website optimization now factors into mobile search ads quality. I’ve seen no indication that Google is considering responsive web design in its definition of mobile optimization. The announcement linked to several case studies and articles illustrating separate sites as the approach.

This is probably a problem with the search engines and not with responsive web design as a technique, but if a company relies on search engine traffic for revenue, it likely won’t matter who is to blame.

Advertising

There’s been a lot written about the difficulty of incorporating advertising into responsive design. Most of the focus has been on the fact that ads aren’t designed to be responsive breaking responsive layouts.

But there is another more structural issue: sometimes advertisers just want to advertise on one form factor and not another. App developers who want to drive app store purchases may not be interested in advertising on desktop. An advertiser interested in location-based advertising is also unlikely to consider responsive advertising desirable.

Will responsive web designs be able to participate in the growing mobile advertising opportunity?

Analytics

Most web analytics tools that support mobile provide an option to use a server side way of tracking instead of tracking via JavaScript. This is offered because many older devices either don’t support JavaScript or support it so poorly that using JavaScript-based tracking code is problematic.

Bryan and Stephanie Rieger have talked about how in their experience switching to the server-side code will show a lot more mobile traffic from a wider variety of devices than if you stick to the JavaScript version.

The problem is that you can’t run both the JavaScript and the server-side (mobile) variant on the same page. The analytics vendors recommend using the server-side code on your mobile site and the JavaScript one on your desktop site because the JavaScript version has a lot more data and features than the server-side one.

Sites using responsive web design will need to choose between more accurate data about the total mobile traffic (server-side tracking code) or deeper information about a small set of visitors (JavaScript tracking code).

Content Delivery Networks (CDNs)

On a responsive web design that takes care to provide only the assets that are appropriately sized for the device requesting the page, the images will vary based on the device. This causes problems with content delivery networks that have become accustomed to being able to cache a single asset for all devices or at worst caching a desktop and a mobile version of the asset.

As Ronan Cremin put it, CDNs may now need to cache different images based on the entire spectrum of devices accessing a site. FWIW, depending on how they are implemented, this can be a problem for separate sites as well.

One way in which RWD does not resemble the transition to standards

The move towards responsive web design has been compared by many to the changes that happened when web design went from being table-based to using web standards and CSS layouts. The Boston Globe’s new site has been compared to the impact that the ESPN and Wired redesigns in proving the value of web standards.

It may be that my faulty memory, but I don’t remember a similar list of potential drawbacks from a business perspective to making the change to CSS-based layouts. If anything, things standards-based layouts had great business benefits because of the increased semantic markup leading to better search rankings and the leaner code helping with page performance and bandwidth costs. Yes, like responsive web design, retraining staff and changing infrastructure could be a major undertaking, but there wasn’t concern that making a change would negatively impact search rankings or make analytics more difficult.

And I honestly don’t know how big of a problem any of these things are with the exception of the analytics problem which seems clearly to be a pickle. It may be that search engine rankings aren’t impacted at all. But the fact that we don’t know seems like something that should be sorted out and considered if those things are critical to the success of a given project or client.

And to be 100% clear, I’m not saying people shouldn’t do responsive web design. Even if you were to build separate sites, you should still do responsive web design for the separate sites.

I’m simply saying these are challenges and concerns that I don’t think we’ve currently got good answers for.

But we’ve got a problem. We came up with a fun theme (Zombie Apocalypse!) to make the workshop interesting, but we’ve heard people were reluctant to register for the workshop because they didn’t get it.

Since we heard about the registration problem, we’ve lept into action:

• We’ve rewritten the workshop description so it is clearer what people will learn at the workshop.
• We’ve posted a fun preview of the talk. The preview made me giggle multiple times when I read what Lyza had wrote.
• We’re here asking for your help.

We need your help getting the last minute word out. If you can take a moment to share the event, we would appreciate it. Particularly if you know people in New York who would benefit, we would be grateful if you pass the word onto them directly.

And of course we have discounts to share

WebVisions has provided us with a way to save 40% on conference passes. There are two options:

1. Save 40% off a conference pass, get a FREE pass to Thomas Phinney’s “Web Typography Best Practices” workshop ($250 value) and a 60-day unlimited WebINK account (register at http://wvnyc-webink.eventbrite.com/), OR
2. Save 40% on conference passes to WebVisions NYC and receive a FREE Workshop pass ($250 value) to Kevin Hoyt’s “Web Standards Playground” (register at http://wvnyc-adobe.eventbrite.com/).

I honestly had to read that a few times to make sure I understood the deal correctly. Seriously, 40% off and you get a free workshop? My guess is that Adobe and WebINK are helping sponsor the discounts which is pretty cool way to get into a workshop and save money.

WebVisions is a fantastic event

WebVisions is new to New York, but it has been going on in Portland for several years now. It always has fantastic speakers and the line up in New York is no different. Please help us make the event a success.

Thanks in advance for spreading the word. We greatly appreciate it and promise we’ll be less cutesy and more descriptive in our workshop abstracts from now on.

One of common conclusion from the commenters is that our current IMG tag isn’t going to cut it. That we need some sort of replacement that is future friendly. This isn’t the first time the idea of expanding or replacing the IMG tag has come up.

I promised to collect some of these proposals so we can discuss their relative merits.

Current proposals and discussions to replace or extend the IMG tag

As far as I know, there hasn’t been a formal proposal submitted to any standards bodies, but there have been several conversations worth highlighting. I was going to try to summarize the various proposals, but there hasn’t been a lot of consensus. I’m afraid that to get up to speed, you’re going to have to read the threads.

Adaptive Images on W3C HTML mailing list

At the end of May, Dom Hazael-Massieux kicked off a lengthy thread talking about Adaptive Images with two ideas: a srclist attribute and new image file format that would be a text file containing a list of images.

The thread continues with many other ideas including new http headers, progressive image formats, and general media formats with queries.

BTW, Adaptive Images has been added as a placeholder on the HTML.next list.

Discussing Alternatives For Various Sizes Of The Same Image & Introducing src Property In CSS As An Option by Robert Nyman

Robert asks the question, “whether various sizes of the same image is really content or presentation?” If it is presentation, then it should be in CSS. Again, great discussion in the comments.

Responsive images using CSS3 by Nicolas Gallagher

“This method relies on the use of @media queries, CSS3 generated content, and the CSS3 extension to the attr() function.” This means it relies on already existing standards without creating anything new. Unfortunately, it doesn’t prevent multiple images from being downloaded and currently only Opera supports the CSS3 content property. That said, if we could get browser makers to change download behavior, this could work with existing standards.

My take on adaptive images, Responsive images – hacks won’t cut it, and Simpler responsive images proposal by Yoav Weiss

No one has been blogging more about the need for a better solution than Yoav. His proposals have changed over time. The simpler responsive images proposal is his latest version, but they are all worth reading to see his thoughts and the feedback on each post.

add html-attribute for “responsive images” on WhatWG mailing list

Anselm Hannemann started a recent thread on the WhatWG mailing list proposing using media- and inline media queries to provide different images. One of the things notable about this thread is that there are some on the list who don’t think the current situation is a problem or if it is a problem, that it is a niché use case. We have some education to do.

Comments on Responsive IMGs Part 1 and Part 2

It seems weird to link to my own posts, but the comments on each post contain some good suggestion. Scott Jehl said, “It’s unfortunate the comment streams of these images posts are separated. Good stuff going on in both.” I agree. Best I can do is link them up with this post.

What are our goals for a replacement for the IMG tag?

As I read through the conversations about the potential replacements or extensions for the IMG tag, I’m struck by the fact that people seem to all see the same problem, but haven’t yet come up with common criteria that could be used to evaluate different potential solutions. Until that exists, we won’t have consensus.

For example, I would love to have the browser send more data via HTTP headers that would allow us to make determinations on the server about what size image to send. But I don’t think that will work as a replacement for the IMG tag because we need something that will work for HTML widgets where the server isn’t part of the picture.

(Psst… but seriously browser makers, more headers would be great!)

So what should be our criteria. Here is start from my perspective:

• It should be an HTML element and not solely CSS because IMGs are often part of the content. IMGs are semantic.
• The solution should work without server content negotiation so that it can be used for HTML widgets. This doesn’t preclude servers being part of the solution, but we need a solution that will work if servers aren’t in the mix.
• Current caching and proxy strategies cannot be ignored. Because of this, different image sizes likely need to be at unique URLs or the wrong size image for a given user will end up cached at the edge of the network.
• It should support arbitrary image sizes and pixel density.
• It should support art direction decisions to change the image at different sizes.
• It should be a framework that will allow for future expansion based on factors beyond screen size. For example, if the browser provides information about the speed of the network connection, the designer or developer should be able to decide on the most appropriate image. We don’t have to define this now, but we shouldn’t box ourselves in to only looking at screens size.

That’s my start on criteria. What did I get wrong? What would you add? And of the various IMG tag replacements that have been suggested, which do you think holds the most promise?

When I started working on this project two months ago, I thought I would get to the end and be able to say, “Here are the three approaches that work best. Go download them and figure out how to integrate them into your systems.” Oh naivety!

What I’ve found is that there is no comprehensive solution. Instead, we have several months of experiments. Each experiment has its own advantages and disadvantages.

Because of this, the best thing we can do is understand the common elements and challenges so that we can start to pick the best parts of each for building our own solutions.

So um… this is a long post. Sorry.

Abandoned approaches

Dynamic Base Tag

Many of the early techniques used javascript to dynamically change the base tag. The new base tag would add directories into the path that would be used to indicate what size image should be retrieved. After the document loaded, the base tag would be removed.

Unfortunately, this approach ran into race conditions that I described in part 1. I found that Google Chrome was downloading both the mobile and desktop images. Scott Jehl found the problem to be a difference between how inline and external javascript is handled. He submitted a bug to webkit which has been marked as “won’t fix” because:

Inserting base element effectively changes all the subsequent URLs on the page. Any script may insert one so to avoid double loads we could never load anything else as long as there is a pending script load. This would mean disabling preloading, which is out of the question.

In theory, you could still use a dynamic base tag inline, but the Filament Group has been primarily using a cookies-based approach instead which seems safer.

Temporary images

Another early technique was to have the src of imgs pointing to a temporary image and then having javascript replace the source with the correct file path. In most cases, the image was an one pixel transparent gif set up with caching which would hopefully prevent the browser from requesting it more than once no matter how many times it was referenced in the page.

The problem with this technique is that if javascript isn’t present, the browser will never download the images.

Javascript-based solutions

Where do you store the path to alternate versions of an image?

If the the img points to ‘small.jpg’, where do you put the information that ‘large.jpg’ is what should be loaded on larger screens?

URL parameters

One solution is to put the path to alternate versions of the image in the src attribute as url parameters. In its simplest form:

<img src="small.jpg?full=large.jpg">

If you have multiple sizes of images, they simply get added as additional values on the url. The key to making this work is coupling it with an .htaccess file.

Potential CDN, proxies, and caching issues

The big drawback to using URL parameters is that it may cause problems with content deliver networks and proxies that doesn’t pay attention to url parameters when caching content. Some caching algorithms ignore anything that has a URL parameter on it which means that pages will slow down because images aren’t cached.

Others will simply cache the first version of the image they see. If the first person behind a proxy cache happened to view the page on a mobile phone, then every subsequent user sees the mobile size image until the cache expires.

How likely is this to be an issue? I had the same question so I asked Steve Souders. He says that it is enough of a problem that you can’t ignore it. This echoes comments by Bryan and Stephanie Rieger at Breaking Development about problems with caching and CDNs.

Therefore, I think we should be looking for techniques that don’t use url parameters.

Examples of this approach:

• Responsive Images JS Master Branch
• Responsive images alt
• Responsive Images and Context Aware Sizing
• Responsive images with Doubletake.js
• Responsive images with PHP and jQuery
• Responsive images using cookies
• Context aware responsive images

Data attributes

Instead of putting the file path into the url parameters, the information is put in one or more data- attributes. For example:

<img src=”small.r.jpg” data-fullsrc=”large.jpg”>

Which element has data attributes added to it and how many are added depends on the technique.

Looping through every img tag

The only disadvantage to this technique that I’m aware of is the fact that the javascript has to loop through every image, check for data attributes, and then modify the src attribute depending on screen size. This is probably not a big problem on desktop browsers which is where the loop is mostly to be used.

Examples of this approach

• Responsive Images JS data-attribute-based branch
• Testing Responsive Images
• Creating responsive images using the noscript tag

Assumed file structure

In this variation, the file path isn’t included in the HTML document. Instead, it is assumed that the images are put on the server in a regular fashion. For example, all small images might be in /images/sml/ whereas large images are in /images/lrg/.

If this is true, then the html doesn’t need to provide both paths. It just needs to provide the image filename (e.g., boat.jpg) and then let javascript modify the src to be appropriate for the size of the screen (/images/lrg/boat.jpg for desktop).

Examples of this approach

• responsive-images-alt
• Adapative images

Dynamic file names

One of the things that I suggested in part 1 was that we might need arbitrary image sizes. Some of the solutions are built around the assumption that you can pass the dimensions that you want in the url and get back an image at that size.

Because the images are resized on the fly, there is no need to store alternative file paths in the HTML document. Javascript will modify the filename from something like ‘boat.jpg’ to ‘boat-480×200.jpg’. There is no issue with caching or CDNs because each image is unique.

Some images cannot simply be resized

This approach doesn’t provide a good solution for manually choosing images at different sizes. It assumes that resizing images will work in all cases which we know is not true.

Examples of this approach

• Responsive Images JS meaningful branch
• Responsive images and tinySrc

Role of .htaccess (or similar rewrite rules)

Many of the solutions rely on server rewrite rules. The examples are usually written using Apache .htaccess files, but they could be any sort of rewrite rule.

Lets look at a snippet of the .htaccess file from Responsive Images JS cookie-based branch to see how rewrite rules are being used:

RewriteEngine On
#large cookie, large image
RewriteCond %{HTTP_COOKIE} rwd-screensize=large
RewriteCond %{QUERY_STRING} large=([^&]+)
RewriteRule .* %1 [L]


The first line turns rewrite rules on. Next comes a couple of conditions (RewriteCond). The first checks to see if there is a cookie called rwd-screensize that has the value of large. The second checks to see if the query string for the url contains a value for large. This .htaccess file is looking for something like:

<img src="small.jpg?large=large.jpg">

If both conditions are met—the cookie is set to large and there is a large value in the query string—then the rewrite rule will send the file that was specified in the query string (in the example above, that would be large.jpg).

The rwd-screensize cookie is set by javascript after it tests for the screen size.

How do you prevent the browser from downloading multiple images?

With the basics out of the way, we can now get to the tricky part. As mentioned in part 1, intercepting the browser before it starts downloading images so that you can evaluate and possibly change the source of those images is tricky and may result in race conditions.

Now that the dynamic base tag has been ruled out, there are two main techniques that remain.

Set a cookie

This is the method that the Filament Group settled on for the Boston Globe. Javascript is inserted into the head of the document so that it evaluates as soon as possible.

After it determines the screen size, it sets a cookie. Every subsequent image request sent from the browser will include the cookie. The server can use the cookie to determine the best image to sent back to the user.

Potential problems

If the browser doesn’t support cookies or the user blocks them, then the javascript will have no effect.

Also, Yoav Weiss has done some testing and shared results that indicate that duplicate files will be downloaded by IE9. Firefox will download duplicate files if the script is external, but not if it internal. This suggests that cookies may also be subject to the race condition problem that caused us to abandon the dynamic base tag approach.

Examples of this approach

• Responsive Images cookie branch
• Responsive images using cookies
• responsive-images-alt

Noscript tag

Within the last couple of months, new techniques have emerged that use the noscript tag as a way to prevent extra downloads. The first post I saw describing this technique was by Mairead Buchan. She describe it as having “ the elegance of a wading hippo”. Despite that description, I think this technique holds promise.

A cleaner implementation of the noscript approach was created independently by Antti Peisa. Here is the html:


<noscript data-large='Koala.jpg' data-small='Koala-small.jpg' data-alt='Koala'>
<img src='Koala.jpg' alt='Koala' />
</noscript>


The values for the various sizes of image tags are stored in the data attributes on the noscript tag itself. Antti then provides sample jQuery code used to process the image:


$('noscript[data-large][data-small]').each(function(){
    var src = screen.width >= 500 ? $(this).data('large') : $(this).data('small');
    $('<img src="' + src + '" alt="' + $(this).data('alt') + '" />').insertAfter($(this));
});


These lines go through the document to find noscript tags with the appropriate data attributes. It tests for the screen size and then inserts a new img tag with the appropriate image path and alt tag.

No race conditions!

When using the noscript tag, there are no rendering race conditions. The image in the noscript tag never starts downloading. Mairead explained that “it works because children of the <noscript> tag are not added to the DOM”.

This makes sense. The browser knows if javascript is available before it starts rendering a page. If javascript is available, there is no reason to worry about doing anything with items inside the noscript tag. If they aren’t getting added to the DOM, they certainly aren’t going to get downloaded.

This technique also has fallbacks if javascript isn’t enabled and doesn’t rely on cookies or htaccess files.

Potential gotchas

The biggest gotcha will be devices that profess to support javascript, but have poor implementations. For example, Blackberry 4.5 has javascript, but javascript cannot manipulate the DOM. Ergo, the noscript tag will not get used because scripts are available, but the script won’t successfully add a new img tag so no images will show.

Please note, this is speculation on my part. I know how Blackberry 4.5 behaves, but I haven’t tested this particular approach on a 4.5 device.

Even though this approach does not create a race condition, it is important that the javascript execute as quickly as possible. Inserting all of these images may require the browser to reflow the page. It also may cause the browser to load assets less efficiently because it cannot start prefetching assets.

Because of the need to execute as quickly as possible, it makes sense to remove the jQuery dependency from Antti’s javascript and put the code in the head of the document.

Examples of this approach

• “Creating responsive images using the noscript tag
• Testing Responsive Images
• Responsive context aware images without cookies or server logic

Is screen size the right thing to look at?

Most of these techniques rely on the size of the screen to determine what the image size should be. Andy Hume points out that the size of the screen may be misleading. He writes:

The content driven approach to fixing this is to decide which image to load based on whether the image will be stretched beyond its true pixel width. If you stretch an image beyond its true width it begins to look pixelated or blurry. In this scenario, we want to load in a higher resolution version of the image.

Andy’s fork of the Responsive Images JS tackles this problem (and adds support for nginx).

Boston Globe Responsive IMGs are Busted

I’ve been looking forward to the Boston Globe’s launch for quite some time. It is a tremendous feat of engineering and design. It has the volume of traffic necessary to test different approaches to responsive IMGs and see what works and what doesn’t.

The technique that they chose to use combines data attributes with cookies. Unfortunately, responsive IMGs are currently broken on the Boston Globe site. This is a known problem and they are working on fixing it.

The upshot is that we don’t yet have a large scale deployment of any of these techniques that we can interrogate and point to as validation that a particular combination is battle-hardened.

Most promising javascript only techniques

In my mind, cookies plus data-src and noscript are the two most promising techniques. Both have problems, but they have far fewer gotchas than other approaches.

Server side solutions

Most of the javascript techniques require little, if any, support from the server. There are alternate approaches that leverage the server for a bunch of the heavy lifting.

User agent string parsing

A few people have demonstrated solutions that do light-weight user agent string parsing to identify various mobile phones. If the user agent can be identified as iPhone or Android, then declare the device mobile and set the image size appropriately.

Unlike a lot of developers, I don’t have a problem with device detection based on user agent string. But if you’re going to start doing it for mobile, you have to take on real device detection via WURFL, Device Atlas, etc. Simplistic regular expression matching and assumptions about screen sizes isn’t going to work.

Device detection

There are a couple of different approaches that rely on device detection to determine the screen size and deliver an appropriate image back. Device detection databases are pretty good about having basic information like screen size.

Sencha.io Src (formerly called TinySRC)

James Pearce created a fantastic service called TinySRC. He later went to work for Sencha and TinySRC became Sencha.io Src. Sencha.io Src automatically resizes images for you. You reference Sencha.io Src in your img stag like this:

http://src.sencha.io/http://www.myapp.com/myimg.jpg


When a browser requests the url above, Sencha.io Src will look up the user agent of the device making the request to determine what size image is appropriate. It will then grab the image from your server and resize it. It then caches the resized image so that subsequent requests can be served quickly.

In addition to the automatic mode, Sencha.io Src will also allow you to specify specific sizes that you would like the image resized to.

Combining Responsive Images JS with Sencha.io Src

Andrea Trasatti forked Scott Jehl’s Responsive Images JS to combine responsive IMGs with TinySRC. The script finds the screen size using javascript and then uses htaccess to request the image at the correct size from Sencha.io Src.

Andrea’s version was written fairly early. It still uses dynamic base tags, url parameters, and results in “1 HTTP request for every image that we might avoid”. But all of these problems could be remedied by combining what Andrea started with some of the newer approaches.

Potential drawbacks

First, if you have a religious aversion to device detection, then you probably don’t want to use Sencha.io Src or you need to use it in a scenario where can specify the image size that you want.

As an aside, I’ve found it funny to see people who speak ill of device detection and user agent strings suggest that people use TinySRC. I once saw a slide deck that dismissed device detection and then a couple of slides later talked about how great TinySRC is. If only they knew.

On a more practical level, you have to evaluate whether or not the service will remain up and what happens if all of your content points to sencha urls that suddenly go away. I don’t think Sencha is going to go anywhere anytime soon. I know James well enough to know he’ll want to keep this service running forever if he can. But even all that said, looking at the long term availability of a service is something that needs to be considered.

WURFL-based solution

WURFL is the largest open source device database. After attending the Breaking Development conference earlier this month, Carson McDonald was inspired to develop a WURFL-based solution for images. It’s awesome to see something come together so quickly after the conference.

(BTW, Breaking Development is the best conference in North America for web on mobile. Registration for the next event opens today. You should attend!)

Carson notes that his approach will likely have the same problems with CDNs and caching because different size images come from the same url.

Image resizing services

Google’s mod_pagespeed

Google’s mod_pagespeed Apache module automates many performance tasks and includes an option to scale any images on the fly. There are many ways to scale images (GD, ImageMagick, etc.). I decided to call out mod_pagespeed because it was one I hadn’t considered until I saw it suggested in a forum. I don’t know of anyone who has explored how it might be used in an responsive IMGs solutions.

Combining client and server approaches

Adaptive Images

As you can probably tell by now, there are few solutions that you can simply install and forgot about. Most require at minimum changes to the way you mark up the page. The two solutions that come closest to be plug and play are Sencha.io Src and Adaptive-Images.com.

Adaptive images was developed by Matt Wilcox. It turns the premise of Responsive IMGs on its head by assuming that the markup on the page will contain the large versions of images and will not start with the mobile versions.

The solution consists of three pieces:

1. A small snippet of javascript placed in the head that sets a cookie with the screen width and height.

<script>document.cookie='resolution='+Math.max(screen.width,screen.height)+'; path=/';</script>

2. A .htaccess that rewrites all requests for images to a php file. You declare directories that you want to exempt from this rewrite. For example, you don’t want your media query savvy CSS background images getting routed through the php file.

3. The php file which resizes the image based on breakpoints that you can configure.

The best part of Matt’s solution is that as long as you can separate out your image files so you can exclude ones that shouldn’t be resized, you can implement this technique without making any changes to your existing markup. Existing pages and posts will suddenly have different image sizes.

And now for the problems

Come on, by now you weren’t expecting it to be that simple did you?

Because the images start with the large size, if javascript is not available, the large size will be delivered. The most common devices to not have javascript support are older feature phones. The type of devices that will choke and even crash on large images are older feature phones.

This technique also suffers from the same race conditions that most of the javascript solutions do. The cookie has to be set early to avoid extra downloads.

Update: Matt commented below and points out that the default settings will result in a small image being delivered if javascript isn’t present. The markup will point to a large version, but the php file returns a small version. All of this is configurable.

Also, he is right that the result of the race condition would not be multiple downloads. I think the race condition still exists with different drawbacks, but I’m going continue the conversation in the comments where Matt and I can converse.

I also missed the fact that the url will stay the same regardless of the size of image which can cause issues with CDNs and proxy caching as noted earlier.

Yiibu profile approach

Brian and Stephanie Rieger presented the work they did for browser.nokia.com at Breaking Development conference. For that project, they invented a new way to combine client side information with device detection.

When a browser first requests something from the server, they don’t know anything about the device. So they check with a device detection database to see what they can find out about the size of the screen (and other details). They then check their own local database of tacit knowledge. This a database of things they’ve learned about how specific browsers work and any overrides they want to use. They use the combination of this information to deliver the appropriate HTML, javascript and images.

Once the browser gets this information, a javascript runs that tests the various aspects of the browser including screen size. It then stores this information in a profile cookie.

On the second request, the server receives the profile cookie and compares it to the information it has in its tacit database. It may update the tacit database. It combines the information into a revised profile combining server side information with client feature detection data.

I’m likely doing a poor job of describing the solution. Your best bet is to look at their slides:

• Adaptation: Why responsive design actually begins on the server
• Pragmatic Responsive Design

This combined technique mitigates the problem of first load without any of the race conditions or potential problems that the client-only solutions have. It also extends beyond images to other content and javascript.

Sounds great. What’s the catch?

It is a complex system and requires significant changes to infrastructure to support. Bryan and Stephanie have published the approach, but the code isn’t available for download. It may be coming, but they took a well-deserved vacation after spending most of the summer working on the Nokia Browser project.

Probably the biggest problem with this approach is that most of us are not the Riegers. They have been doing mobile web for years. Their tacit knowledge of devices is exceptional. Freaking geniuses. That’s hard to replicate.

The same is true of the Boston Globe project. The team working on that included significant portions of the jQuery Mobile team and the guy who coined the phrase responsive web design. Few of us are going to be so lucky on our next project.

Summary

As I’ve reviewed the various techniques, I keep thinking back to something Andy Hume said in response to part 1:

Our current solutions are hugely dependant on the current (and undefined) behaviour of browsers in regard to the page-load race conditions you mention. For example, most responsive image implementations would be compromised if a particular type of look-ahead pre-parser (http://goo.gl/TyzTi) began to speculatively download images before actually parsing the HTML or executing any script. (I half expect us to get bitten by this any day.) One way or the other we need to consort with browser makers to get future-friendly.

That’s the truth of it. Most of these techniques are based on our hope that browsers continue to download assets in the order we have observed to date. If the the order changes or if browsers start pre-parsing more aggressively, the whole house of cards may fall down.

In part 3 of this series, I’m going to look at the conversations going on about ways to change the img tag or replace it with something that will work better with multiple file sources.

Sources and Acknowledgments

I reviewed 18 different techniques for this post. My notes are captured in a Google spreadsheet that you are welcome to review for detailed comments on each library. Thanks to everyone for publishing their thoughts and experiments. I learned a lot from each one.

This series wouldn’t have been possible without the assistance of Scott Jehl and Bryan and Stephanie Rieger. Scott in particular helped me sort out the problems with the main Responsive Images JS library. Thanks to all three of you for putting up with my many naive questions and for taking the time to explain all of the work you’ve been doing!

A recent Smashing Magazine round up of responsive web design techniques included several new approaches for handling IMG tags which makes it the perfect time to dig into this problem and the potential solutions in more depth.

Why IMG Tags Suck for Responsive Web Design

If you want your site to load as quickly as possible, you do want to deliver larger files than are needed. Many responsive web design sites provide mobile devices images at sizes appropriate for desktop and ask the mobile device to resize the image.

In my research, I found nearly 80% decrease in file size by delivering images at the actual size they were going to be used on a mobile device.

So what’s the problem with the IMG element in responsive designs? Unlike CSS images which can provide different source files based on screen resolution using media queries, IMGs have a single source attribute.

What are Responsive IMGs?

Responsive IMGs are images delivered using the HTML IMG tag that come from different sources depending the screen size. There are many different techniques for accomplishing Responsive IMGs.

As far as I can tell, Scott Jehl first coined the phrase Responsive Images to describe a javascript solution to the img source problem. He also referred to Responsive IMGs as a general term recently so I’m hopeful he doesn’t mind the fact that I’m extending his definition to describe any technique that attempts to provide images at an appropriate size for a responsive design.

Responsive IMGs Challenges

There are some common challenges that any Responsive IMG technique will face. As we review the various techniques that have been proposed, we need to keep these challenges in mind.

Minimum Bar: Start with Mobile, No Extra Downloads

Scott Jehl set a minimum bar for Responsive IMGs by stating they must do the following:

1. Start with mobile img
2. Upgrade to larger size without downloading both

Both of these are worthy and necessary goals.

The First Page Load Problem

Any solution that relies on client-side scripting to make a decision about what image source to display will suffer from a first page load problem. The first time someone visits a site, the server won’t know what size image to provide.

Image from Bryan Rieger’s Muddling Through the Mobile Web presentation, photo by wscullin, licensed under Creative Commons.

If javascript is added that determines what image size is appropriate, then this information can be retained for the user session via cookies or similar techniques. In theory, on subsequent requests the server can make a decision about what size image to include in IMG tag.

FWIW, the speed of first load is a big deal. The speed of a person’s first experience can dictate their impression of a product and company. Google, Yahoo and others have talked about how minor speed differences makes a big difference in usage of their products.

Rendering Race Conditions

Techniques that rely on adjusting the image source attribute via javascript need to make sure that the modification happens before the image requests start.

Browser makers have done a lot of work to download as many assets as possible at the same time. Usually this is a good thing. But in the case of responsive imgs, the javascript needs to evaluate what size image to retrieve before any image requests start.

A lot of earlier work was done using dynamic base tags. This worked when the javascript was inline in the head tag, but failed to prevent images from downloading twice when an external javascript file is used.

The upshot is that nearly every client side technique requires deep understanding of the order in which different browsers process and download assets. Or more realistically, each approach needs to be tested extensively.

Content Delivery Networks and Caching

When you deliver different size images at the same url, you can run into problems with CDNs and other caching at the edge of the network. If the first person to request an image is on a mobile phone, people who follow via the same CDN or cache will also see the mobile-optimized image even if they are on desktop unless consider CDNs in your strategy.

Future Friendly Responsive IMGs

If we accept that the “quantity and diversity of connected devices—many of which we haven’t imagined yet—will explode”, then we need to consider look for solutions that are future friendly. In addition to the current experimentation, we need to start thinking about what a long term solution might look like.

For example, many of the early solutions for Responsive IMGs consist of two size images: one for desktop and one for mobile screen sizes. Will two image sizes really suffice for all of the devices that are coming?

Also, a lot of the solutions right now tackle one part of the problem. They may tackle the client side changes to switch the image source, but leave as an exercise for the developer to figure out how image resizing will be handled. For shared libraries, limited scope makes sense.

But as we look at what systems will need to do to be successful in the future, we need to think about what we want out of both the server and client side.

Here are some of the things that I think a future friendly technique will need to consider:

• Support arbitrary image resizing — We cannot anticipate what screen sizes may be coming. We need systems that handle image resizing automatically and support any arbitrary size needed for a particular page.
• Art direction can override automatic resizing — Not every image can be resized without losing the meaning of the image. Sometimes cropping an image may work better than resizing it. Automatic tools need to easily support manual override.

• Support for higher resolution displays — What do we do with the iPhone 4’s retina display and other devices sharing similar high resolution screens? It is an open question about whether we should deliver higher resolution images to those devices given the performance hit that will occur if the person is on a slow connection.
   
  But regardless of how we chose to handle it right now, it is clear that the trend towards more pixels per inch on displays is not going away. If anything, we’re seeing indicators that higher density will soon be available on desktop displays as well.

  This means that our current definition of what is a large image for web is probably too small for future devices. With that in mind, it probably makes sense for systems to accept the highest resolution image possible—even if that resolution isn’t currently being used—so that when new devices become available the high resolution source is already available and hasn’t been lost.

• Connection speed should be part of the criteria — We can be much smarter about the size of the image we deliver if we can tell something about the network connection. We need an easier way to get at this information.
• A replacement for the IMG tag? — All of the responsive image solutions are attempting to deal with the fact that the image tag has only a single source. There have been various proposals recently to take a new look at what the tag should be and see if we can find a long term replacement.

That’s my short list. What would you add?

In part 2, I’ll take a closer look at the current alternatives for responsive imgs and which ones hold the most promise.

I have a solution for you. Ask the people you need to convince if they do any of the following:

• Send email to their customers?
• Participate in social media?
• Search engine optimization?
• Advertise online?

Each one of those marketing efforts is based on links. And links don’t open apps.

It seems like a basic concept, but the fact that links can only reliably open web pages is often forgotten.

This is one reason why mobile web has to be part of every company’s strategy. When someone encounters a link via an email newsletter or shared via a social network, they should be able to view that link no matter where they are and no matter what device they are using.

Technically True vs. Practical Reality

Inevitably, when I talk about how links don’t open apps at a conference, someone who wasn’t in the audience will point out that on some platforms like iOS, you can register URL schemes to open apps.

While this is technically true, it isn’t practical for most communication because:

• Not every platform offers equivalent functionality. On Android, the way to invoke applications is intents which works very differently.
• Even if you could somehow create the same url scheme on every mobile platform, the url would only work if the user had your application installed which you can’t guarantee nor control.

While saying that links don’t open apps isn’t “technically” true, it is a practical reality.

Power of Hyperlinks

The realization that links don’t open apps has triggered for me a renewed appreciation of the power of hyperlinks. When people talk about the differences between native apps and mobile web, they usually talk about difference like performance, cross platform development, and other technical factors.

Rarely do we talk about hyperlinks and the power it provides the web. No native platform will be able to replicate the universal utility of links any time soon.

We should stop worrying about whether or not native apps can do certain things better than web technology, and instead talk about what makes the web unique, powerful, and universal.

We’re looking for an enthusiastic mobile developer to join our team: someone who falls on the engineering side of the development spectrum, but is also comfortable with front-end technology.

We’re a small agency focused on building mobile and web solutions for our customers. We believe in cross-platform solutions and advocate a mixture of mobile web, native, and hybrid approaches to mobile development depending on the project objectives.

Our ideal candidate is someone who is flexible, open to new technologies, and a quick learner. Mobile is fast-paced and constantly changing. We’re looking for someone who sees opportunities and challenges amongst the many different mobile devices and their inconsistent behavior.

Cloud Four was founded in November 2007 by four mobile and Web enthusiasts. Our mission is to create usable, inspired mobile and web applications using standards-based technologies. Our clients range from Fortune 500 companies to local businesses, and our projects vary in audience and scope accordingly.

This is a full time position on-site in lovely Portland, Ore. We offer benefits including medical, dental, vision, and IRA.

Job Description

• Research, identify and document client technical requirements.
• Determine and identify appropriate technologies to be used.
• Assist with developing technical project schedules, plans, task assignments and time estimates.
• Assist in strategic planning and requirements gathering.
• Program mobile applications and build mobile web sites.
• Be a positive and enthusiastic contributor to our team.
• Actively, consistently communicate with team members about project process and progress.

Our ideal candidate is:

• able to create a concise, clear plan of action from multiple input sources and stakeholders; flexible and responsive to changes in requirements and scope.
• self-directed; takes an ownership role of complex projects.
• strategy-focused and creative; excited to face new challenges and learn new skills.
• deadline-driven and steadfast about meeting commitments to customers.
• invigorated by learning new technologies and solving new problems.
• an excellent communicator, with the ability to comprehend and articulate technical concepts, both verbally and in writing.
• an independent learner who can quickly apply new skills productively.
• enthusiastic about the job; enjoys solving customer needs.
• a straightforward, honest, team player.
• able to effectively prioritize multiple task.
• comfortable working in a small, start-up environment.

Skills and experience we’re seeking:

• 3-5+ years of relevant technical experience or related background
• Extensive experience with cross-platform JavaScript and DOM scripting
• HTML5, XHTML, CSS
• Server- and client-side web site or application programming (more engineering than design)
• device detection for mobile web
• PhoneGap or other hybrid mobile app development
• iPhone and/or Android development
• Strong problem solving and analysis skills
• Strong competency in web technologies and development
• BA/BS or equivalent

To Apply

Email your cover letter and resume to jobs@cloudfour.com. No recruiters please.

We all agreed that when a mobile web site is well-design and contains all of the functionality needed, the need to switch to the desktop site goes away.

However, as users of sites, we don’t like it when the link to the desktop version isn’t present. Providing a link to switch to the desktop view is a safety blanket for both developers and users.

As users, we don’t want to see others remove the link to switch to the desktop site because we don’t yet trust people to create mobile web experiences that contain everything we need.

As a developers, mobile is still new enough that we’re not 100% confident that we’ve thought of everything. In some cases, we know that there are aspects of a site that could not be converted to mobile for some insurmountable reason.

The existence of desktop toggle is good test for when our industry has really nailed mobile. When we collectively feel the toggles are unnecessary in most cases, then we’ll know that we as web practitioners have raised the collective knowledge and skill set sufficiently.

We’ll know the mobile web is ready when links to the desktop version disappear.

But if we’re going to limit ourselves to Apple products, I think it is more likely to be the Year of the Cheaper iPhone than the iPad 2.

Before the first rumors of a cheaper iPhone surfaced, I’d been talking to friends about demographic and sales information that indicated to me that the tech press was too focused on high-end devices and missing the lower end of the market.

Because of this, I’m bullish on the impact of a cheaper iPhone and what it would mean for Apple’s smartphone market share. Let me explain why.

The Real Reason Why Android is Successful: It’s Good Enough and Cheaper

It seems like I’ve spent most of my life rooting for companies who made products that were superior in design, but lost to products that were good enough and cheaper.

I was flabbergasted that people would buy inferior products that promised headaches instead of joy. I thought people just didn’t understand how these inferior products were going to cost them much more in the long run with the thousand cuts of poor user experience and design.

At some point I realized that I wasn’t giving people enough credit. They knew that Tivo was a better product, but the DVR that the cable company gave them for free was good enough and cheaper. The same has long been true of Windows machines.

The problem for a lot of Apple fans is that they still can’t understand why someone would chose the obviously inferior product. M.G. Siegler of TechCrunch wrote an article entitled, “Is Android Surging Only Because Apple Is Letting It?” His thesis was that Android was only winning because the iPhone wasn’t available on Verizon. In the article, he wrote:

Now, don’t get me wrong, almost all Android phones are a million times better than the phones we had just a few years ago before the iPhone burst onto the scene. And if the iPhone didn’t exist, there is no question that I would use an Android phone and would probably be very happy with it. But the iPhone does exist. And I simply can’t bring myself to use an Android phone when I know a superior device is out there. That’s my only requirement for me to use a product: it has to be the best.

Most people don’t require their phones to be best. They simply want something that’s good enough to get email, text message, and browse the web. Oh and cheaper is better.

BTW, the predictions of big lines to buy the Verizon iPhone hasn’t panned out and sales have thus far been “disappointing.” So much for the theory that carrier exclusivity is why Android passed iPhone in market share.

But Isn’t Android the Same Price as the iPhone?

A common misconception about the smartphone market is that Android phones and iPhones are essentially the same price. Both the Samsung Fascinate (Galaxy S) and the iPhone 4 cost $199 with a two-year contract.

But the Android phones don’t stay at their launch price point. Verizon had a large television campaign last fall that offered a buy one get one free offer for the Fascinate. Verizon’s site currently lists 13 different Android models for under $100.

That’s why the average selling price (ASP) is so important. On average, the iPhone costs twice as much as its nearest rival:

Q2 2007 to Q2 2010 Average Selling Price. Source: Asymco

The lower ASP for Android devices is what allows carriers and retailers to offer steep discounts on these devices. And cheaper phones are important because there is a lot of growth at the lower ends of the market.

Have you heard of the Samsung Freeform?

No? I hadn’t either until I noticed it was the number three phone in terms of impressions in Millennial Media’s March 2010 mobile mix report.

Millennial Media’s report tracks the number of ad impressions delivered to a given phone. As you might expect, the top phone is the iPhone and the top ten list contains a mix of Android, Blackberry and iOS devices.

But amongst those well-known devices is the Samsung Freeform. The Freeform was still the number six phone in the report as late as December of last year.

The inclusion of the Samsung Freeform on this list stood out like a sore thumb. I had to know more about this phone.

It turns out that the Samsung Freeform is one of those feature phones that start to edge into smartphone-like capabilities. It has a keyboard for texting and a reasonably capable browser.

The phone is only available through MetroPCS. Right now, you can get it for $49 unsubsidized.

But more importantly, you can get unlimited voice, text and web on the Samsung Freeform for only $40 per month.

Growth at the Low End of Smartphone Market

Around the same time I learned about the Freeform, a Comscore survey in Europe found that “smartphones are generally seen as luxury devices that come with big price tags and high monthly tariffs, yet the largest segment of the market and the one demonstrating greatest momentum is actually the low to mid tier.”

I haven’t found a similar study of growth rates in the United States, but I have found other evidence that seems to support the theory that significant growth in smartphone market is happening at the low price points.

U.S. Minorities Lead Caucasians in Mobile

Over the last year, there have been numerous studies showing that minority adoption and usage of mobile is outpacing caucasians:

Pew Internet Research found that African-Americans and Latinos use more mobile data applications. Nielsen found that a higher percentage of minorities both own smartphones and recently acquired smartphones.

It probably goes without saying, but census data shows that minority populations still have lower household incomes than caucasians. Obviously, lower prices will be an important feature for people with less discretionary income.

Android Growth Due to Lower Prices

As I stated above, I believe Android’s skyrocketing growth can be attributed to being good enough and cheaper. The last comparison of income levels for Android and iPhone owners is from Q1 2010. At the time, 36% of Android owners had household incomes of less than $50,000 versus only 22% of iPhone owners. I suspect the difference is more exaggerated now.

Therefore, Android’s success is further proof that growth is happening at the lower end of price spectrum.

The Rational for the Cheaper iPhone in a Single Chart

A couple of weeks ago, I came across a pie chart from Comscore that clearly explains why Apple was rumored to be making a cheaper iPhone:

If you read the Comscore blog post that this chart comes from, you won’t find anything about the cheaper iPhone. The post focuses on how valuable iPhone subscribers will be to Verizon compared to other smartphone owners because iPhone owners have higher household incomes.

According to Comscore, 81% of iPhone owners have household incomes greater than the U.S. median household income ($44,389).

TNS Global found similar results in a survey noting that “iPhone users are also younger, but the most highly educated, employed as a manager or professional and earning more than $100K per year.”

Does Apple care about the low end of the market?

When I tweeted about the above chart, I got a lot of feedback from people who were confused about what I thought the chart meant. My friend Jonathan Stark jokingly asked if BMW was going to announce a car for under $10k? The implication being that Apple stakes out the high end and doesn’t care about the low end of the market.

I have always thought that Apple cared about market share, but that it wasn’t the top goal for Apple. Apple seems to value:

1. Building the best product they can
2. Selling products with a high profit margin
3. Gaining market share

In that order. They won’t compromise their design ideals, brand or margins to chase the low end.

But if they can create an cheaper iPhone that lives up to Apple’s brand promise and sustains their margins, I see no reason why they wouldn’t pursue the low end of the market given the growth opportunities there.

Until recently when people brought up the idea of Apple pursuing an iPod Nano and iPod Shuffle like approach to the smartphone market, I didn’t think Apple could do it. It didn’t seem like there was enough room to differentiate the iPod Touch from a low end iPhone.

I also had my doubts they could build a product at the low price point without compromising. They can’t decrease the screen size like they did for the iPod Nano or remove it entirely like they did for the iPod Shuffle.

However, I now believe there is a lot of room for Apple to explore the low end market. There are a lot of premium features on the iPhone 4, like the retina display, that could be removed on a low end phone without compromising the quality of the design.

But no matter what I think, we should listen to what Apple COO Tim Cook said about the low end market. Cook recently told an analyst that “Apple did not want its products to be ‘just for the rich,’ and that the company is ‘not ceding any market.’”

Will a Cheaper iPhone Make a Difference? The Biggest Cost of a Phone is the Carrier Subscription

When rumors of the cheaper iPhone first surfaced, many people commented on the fact that reducing the cost of the phone won’t help Apple unless they do something to reduce the monthly subscription cost. I disagree.

The success of Android indicates that even if the monthly costs are the same, that many people will chose the slightly less expensive phone. While consumers in carrier subsidized markets never see the full average selling price of phones, it does seem to make an impact in market share.

Second, if Apple is able create an iPhone that is relatively inexpensive without a carrier subsidy, then people can choose to buy it without a contract or go prepaid. In fact, a cheaper iPhone may be the best way to force lower prices by increasing competition between carriers.

There are nuggets that hint at this strategy in quotes from the recent analyst briefing:

• Tim Cook says “Apple is doing ‘clever things’ to attack the prepaid market.”
• “Apple CFO Peter Oppenheimer said Apple would not let carriers dictate terms, which [Bernstein analyst Toni] Sacconaghi says reinforces, “the notion that Apple might be willing to act to disintermediate carriers with a soft-SIM.”
• “Carrier expansion is a priority for Apple. Oppenheimer noted that Apple has only 175 carriers today, versus 550 for Research In Motion (RIMM).”

A cheaper iPhone available without a contract and with a soft SIM allowing people to switch networks would force carriers to compete on price. If Apple also expands into the prepaid market and signs up lower priced carriers like MetroPCS and Virgin Mobile, the impact on carriers could be as large as the impact of the original iPhone.

But even if they cannot lower the carrier costs, making a cheaper iPhone is the only thing they have full control over if they want to expand the iPhone and reach people with lower household incomes.

A Cheaper iPhone Will Be a Smash Hit

Those who have followed me on twitter or seen me speak at conferences knows that despite the fact I love Apple products, I haven’t been bullish on its prospects of Apple dominating mobile market share. The main reason for my pessimism had been based on other platforms being good enough and cheaper.

Horace Dediu of Asymco recently wrote that he still holds “that 20% smartphone share is possible for the iPhone.” This was my best guess for where Apple would end up as well.

The news that Apple will be releasing a cheaper iPhone changes my view substantially. If Apple is aggressive about the low end of the market, and it sounds like they may be, then the limitation on their market share will likely be their ability to keep up with demand. My off-the-cuff guess is a cheaper iPhone puts Apple at 30 to 40% of the market when the dust settles.

But we don’t need to look that far into the future to know that a cheaper iPhone is going to be a big hit. It is going to be huge this year.

1. Introduction
2. How the sources were selected
3. Types of Statistics Available
   • Sales market share
   • Installed base market share
   • Financial information
   • Platform breakdowns
   • Carrier data
   • Demographic surveys
   • Mobile web metrics
   • Advertising networks reports
   • App store metrics
   • Other fun sources
4. Which stats should you care about?
   • App developers
   • Web developers
   • Marketing
   • Investors
   • Your role here

Introduction

At least once a week, I see people arguing over mobile statistics. Usually, they’re not even arguing about the same thing.

The arguments go something like this:

iPhone fan: Apple is totally kicking ass. The only thing holding it back is the fact it is stuck on this crappy AT&T network.

Android fan: Take off your iPhone blinders. Android has passed the iPhone in market share in the whole world, not just the U.S. The Verizon iPhone won’t make a difference.

iPhone fan: That’s not a fair comparison. You should be looking at all iOS devices, not just the iPhone. If you don’t count the iPod Touch and the iPad, you’re missing the point.

Android fan: Whatever. You’re comparing apples to oranges. Besides, there will be at ton of Android tablets in the next year. This is Windows vs. Mac all over again.

iPhone fan: Whatever. I’ll be sitting here laughing my way to the bank with my Apple shares as Apple gobbles up all of the profits.

Typically, the people arguing aren’t even talking about the same thing. They probably aren’t even asking the same questions or if they are, they are asking questions that are too simplistic like “Who’s going to win?”

There are two things you need to know in order to effectively use statistics on mobile:

1. What statistics are available and where to find them.
2. What question about mobile that you’re seeking to answer.

Until you understand these two things, you can’t use mobile stats to inform your decisions. Worse yet, you may end up fruitlessly arguing with people about mobile only to realize later that you’re not even talking about the same thing.

How the sources were selected

When you have the audacity to call something a “comprehensive guide,” you know the moment you hit the publish button that someone is going to point out something you’ve missed. I not only expect that to happen, I’m hoping it does. I’m looking forward to learning new sources from people who comment on this post.

My bias is for finding free or inexpensive sources of data. We’re a small company and can’t afford expensive reports. That said, many of the sources listed provide their free information as a teaser for more in depth reports that they you can buy.

Types of Statistics Available

Sales market share

Sales market share is the most common statistic used to track the current trends in the mobile market. This information usually comes out a month or so after the end of a quarter and tells you how many products a company or platform sold in the previous quarter.

What this stat is good for

• Following the trends in success of the various platforms and manufacturers to see where the market is headed. This can help you anticipate what platforms or handsets you need to watch next.
• When the entire market is growing as fast as mobile is, a company can have record sales and still lose ground to its competition. You’ll see it here first.

What to watch for when you use this stat

• Sales numbers are not the same as installed base numbers. A new platform may sell well in the previous quarter, but it will take some time before the sales of new products exceed the existing devices that people already own.
• Know whether or not the statistic is measuring platform sales or manufacturer sales. Some analysts only look at manufacturer sales which will tell you how HTC is doing in comparison to Apple, but won’t tell you how Android is doing compared to iPhone.
• It helps to understand the seasonal nature of sales. Apple historically releases a new iPhone model in late Q2 or early Q3. Ergo, Apple sales historically jump in Q3.
• Understand what market is being defined. Most of what I look at is smartphone market share. Some people believe that you should look at the entire sales of a platform. So market share for the iOS platform should include iPhone, iPad and iPod Touch. Even if this argument was correct, you’ll find that it is next to impossible to find data that looks at the world that way.

Sales market share sources

Gartner ( Press releases | Recent example )

Gartner is my favorite source. They have a good reputation and they include both overall device sales and smartphone platform market share. They also have begun tracking tablet market share. Gartner’s data comes out every quarter about a month after the quarter ends. It is usually the last of the big analyst firms to release their numbers. Free information can be found in their press releases or you can pay for detailed reports.

IDC ( Press releases | Recent example )

IDC also has a great reputation. I find their numbers a little less useful because they focus on manufacturers not platforms. However, their press releases will often mention the relative success of the platforms in the prose just not in the breakdown tables.

Canalys ( Press releases | Recent example )

Canalys has been monitoring mobile for quite some time. They are usually one of the first to report the results for the previous quarter. They were also one of the first to start looking at smartphones instead of PDAs. Others have complained that their definition of Android in their Q4 2010 report was including Android forks (OMS and Tapas) that shouldn’t be included. My main beef with Canalys is superficial—the typeface on their site is too small and the site is difficult to read.

Strategy Analytics ( Press releases | Recent example )

Strong focus on mobile, but less well known compared to Gartner and IDC. Does not include platform numbers. They have started covering tablet market share and have some info on mobile internet usage.

ABI Research ( Press releases | Recent example )

ABI has an extensive mobile research component. Much of the value is only available to people who sign up for their research service.

NPD Group ( Press releases | Recent example )

Focuses on the US market. Uses large online surveys weighted to match US demographics and asks recent smartphone buyers what they bought. Often includes information on top five handsets in the US. First analyst to report that Android had passed iPhone which prompted Apple PR, which normally doesn’t comment, to criticize the report. Later analysts validated NPD’s early numbers.

Tomi Ahonen ( Search for smartphone blood bath articles | Recent example )

Tomi provides quarterly analysis in his bloodbath series. He has his own models, but always incorporates the numbers from the major analyst firms. Tomi’s name might as well be Tome based on the fact his posts are always epic in length. As a former Nokia executive, he has soft spot for Nokia which can blind him on occasion, but there is a reason why Tomi is someone the mobile industry continues to read. He also self publishes the TomiAhonen Almanac and TomiAhonen Phone Book.

Asymco ( Posts tagged with market | Recent example )

A relative newcomer, Asymco is a blog run by Horace Dediu. As far as I can tell, Horace isn’t a source of new statistics even though the first place you can hear of new research is often his blog. Instead of new research, Horace provides insightful analysis of the market. He often hightlights aspects of the data that others ignore. He provides great graphs to accompany his pieces and you can download data from the blog into an iOS app where you can manipulate the data. He has a soft spot for Apple, but has a realistic view of the market having recently said that he “still holds that 20% smartphone share is possible for the iPhone.” Asymco is a must read blog.

Installed base market share

Whereas sales market share looks at what was sold recently, the installed base market share—sometimes called subscriber market share—attempts to figure out what percentage of each type of phone is currently in use in the real world. These numbers don’t change as rapidly as the sales numbers.

Because phones will eventually be lost, stolen, broken or replaced, you can’t simply add up all of the phones sold in the past to find out how many phones are currently being used. For that reason, information on the installed base comes from surveying end users.

What this stat is good for

• If you can find a match between installed base and a market that you want to target, it can help you determine what devices you need to worry about.
• It helps you understand how quickly changes in the sales numbers are resulting in changes in the number of people using new devices.

What to watch for when you use this stat

• Almost all of the numbers are based on a particular geographic area and not worldwide data.
• Just because someone has a phone, doesn’t mean they are likely to use the capabilities of that phone in a way that makes sense for your business. For example, if someone has a feature phone, they are less likely to have a data plan and thus less likely to browse the web.

Installed base market share sources

Comscore ( Mobile press releases | Recent example )

Comscore and Nielsen are my go to sources for current information on the installed base of phones in the United States. Comscore reports include both handset and platform percentages. They also include information on mobile content usage. In 2011, they released their first annual report which looks at U.S., Europe and Japan.

Nielsen ( Blog | Recent example )

I like Nielsen’s blog posts better, but the information they highlight varies which is why makes following trends more difficult. (Comscore has the same data from month to month so it is easier to compare). They also highlight interesting information like the fact that “Hispanics, Asians are Most-Likely Smartphone Owners in the U.S.” Bonus points for using a blog format and being easy on the eyes.

Other than Comscore and Nielsen, I don’t have good sources for the installed base of phones. It would be nice to add to this list some sources for data in other countries.

Financial information

I’m the first to admit that I’m not someone you want to take financial advice from. But as I mentioned above, at some point in a debate about mobile phones, someone will issue the trump card that while Apple may not be dominating in market share, that they dominate in profits. Where does that information come from?

The simple answer is that it comes from each companies quarterly financial reports. It’s not hard to find the financial reports of each company so I’m going to leave that as a exercise for the reader. Instead, I’ll want to highlight a few sources that talk a bit about the profit breakdown of the market.

What this stat is good for

• If you’re investing, this is obviously critical to make sure you make smart stock decisions.
• Most companies provide some information about the units sold in their financial statements or their earnings phone calls.

What to watch for when you use this stat

• Unless you own stock in these companies, I’m not sure what good this information does for you. Obviously if a company is in dire financial trouble, that will impact the longevity of a platform. There are theories that we misunderstand the lesson of the pc market and that market share doesn’t matter as much as we think. That we should be watching profits instead. Others say the only thing matters is market share because it has it own momentum. That companies should stomach lower profit margins for a few years while the gold rush is on to secure a large market share that will drive long term value. Who’s right? I don’t know.
• When you compare RIM financials to other companies, note that their financial quarter is one month off from everyone else’s. It makes direct comparisons more difficult.

Financial information sources

Seeking Alpha ( Earnings calls transcripts | Recent example )

I often find little gems come out during the earnings calls for various mobile companies. Whenever I’ve searched for transcripts of those calls, I often end up on sites where I have to pay to read the transcript. Seeking Alpha usually has the transcripts available free of charge.

Asymco ( Posts tagged financial | Recent example

I talked in more detail about Horace Dediu in the sales market share section. His blog is the place I see the most information on profit share breakdowns.

Platform breakdowns

Sometimes you need to find information within a given platform. Maybe you want to know how many handsets are still using a particular version of an operating system to determine if you need to support it.

What this stat is good for

• Determining what versions you need to support.
• Understanding how OS version plays into any platform fragmentation

What to watch for when you use this stat

• Data is usually extremely high level. When you encounter a bug in a particular point release of an OS, it is hard to figure how may people are currently using that point release.

Sales market share sources

Android ( Versions report )

Google provides up to date information on Android versions.

Bada ( Developing Applications for Different Device Model )

Bada is too new to have much fragmentation, but they do describe how to plan for different models. Hopefully they will add platform percentages when they release newer versions of their OS.

Blackberry ( Choosing a target OS )

Decent high level numbers, but doesn’t distinguish between 5.x and 6.x. Also, there can be significant differences between point releases and the inability to know how many people are using a particular point release can be frustrating.

iOS versions ( ReadWriteWeb article from August 2010 )

There is no official source for iOS version breakdowns and no third-party that releases the information on a regular basis.

S40 / Symbian / Nokia ( Forum Nokia | Device breakdown )

With Nokia’s recent decision to move to Windows Phone 7 and the dismantling of the Symbian Foundation, I’m not sure how you find good information for existing market of handsets.

Windows Phone 7 ( App Hub

So new that all of the phones are on the same version. When it does publish data, it will likely be on App Hub.

Carrier data

There is a lot of information available about carrier market share, average revenue per user (ARPU), and what services are being used on each carrier. I generally don’t find this information as useful for our business or customers. That said, some of the information on how phones are being used can be fascinating.

What these stats are good for

• Looking for other ways to augment your plans with services like SMS and MMS.
• Understanding the total market for something like location based services.
• Random information to wow your friends at dinner parties (Did you know the average teenager in the U.S. sends and receives 3,338 text messages per month?)

What to watch for when you use these stats

• General data may not be indicative of what your customers are going to do or the services they use.

Carrier data sources

ABI Research ( One Billion Mobile Broadband Subscriptions in 2011: a Rosy Picture Ahead for Mobile Network Operators )

ABI is often quoted when people are looking for the number of mobile phone subscribers in the world.

Chetan Sharma ( Blog | US Mobile Data Market Update Q3 2010 )

Chetan has a long history in the U.S. mobile industry. His consulting practice helps large organizations understand the mobile market. Every quarter he publishes a market update that contains information comparing the carriers, the services that are being consumed, and the average revenue per user. His blog is also a great source of information on U.S. carriers and wireless usage.

CTIA ( CTIA Reports )

CTIA is an international organization, but its main focus appears to be on the U.S. They survey U.S. carriers every six months and publish a report showing revenue, average call time, number of text messages, etc.

Netsize ( Netsize Guide 2010 )

Netsize publishes an annual look at the worldwide mobile industry. It contains market data on 41 countries as well as interviews with thought leaders.

UN’s International Telecommunication Union ( Stats Index | Jan 2011 Statshot | Country Mobile Penetration Level Over Time )

The UN’s ITU tracks access to mobile networks and competition in mobile across the globe. The Google spreadsheet is very cool.

Mobile Active ( Mobile Data by Country )

Mobile statistics by country. BTW, Mobile Active is an amazing non-profit worth your support.

Demographic surveys

Demographic information is one of my favorite areas of mobile statistics. I believe there are trends in mobile that the tech press misses because they aren’t able to step outside the tech bubble and see how the demographics of smartphone users is shifting from the early adopter tech enthusiast to the general population and what that change means.

What these stats are good for

• If you know the demographics of your customer base, it can help ensure your mobile strategy lines up with how your customers are likely to be using mobile devices.

What to watch for when you use these stats

• The survey methodology is always important, but it is particularly important for demographic information. It is easy to find surveys that claim to have some demographic insight that have sample bias (e.g., only asking people who respond to mobile advertising).

Demographic information sources

Pew Research Center ( Publications on Internet and Technology | Cell phone activities by race and ethnicity )

Every time Pew releases new information related to use of mobile phones, I find something interesting. They’ve researched app usage, teens, race, and age differences.

Nielsen ( Nielsen Wire Blog | Among Mobile Phone Users, Hispanics, Asians are Most-Likely Smartphone Owners in the U.S. )

In addition to the market share information, Nielsen also provides information on demographics. The latest report even included smart phone operating system share by race / ethnicity.

TNS Digital Life ( TNS Digital Life Data Explorer )

Global study of almost 50,000 consumers in 46 countries. Website has really cool data exploration tool.

Mobile Marketing Association ( Research | Press Releases )

The Mobile Marketing Association (MMA) keeps track of data and surveys by others in their research section in addition to conducting their own research. They publish report called the US Mobile Consumer Briefing which is supposed to come out monthly (November 2010 Report). I say “supposed to” because I can’t find the more recent reports on their site which I find confusing. The MMA also often issues press releases containing interesting information like the the fact that over half of U.S. consumers planned to use their mobile phone for holiday shopping last year.

Demographic articles I find interesting

I don’t have very many reliable sources of demographic data. I went through my bookmarks and nearly every link came from Pew or Nielsen. So instead of listing more sources that may not have a lot of demographic data, I thought it might be interesting to look a some demographic articles that I find fascinating.

How the Verizon iPhone Announcement Could Influence the Mobile Market

While this Comscore blog post is primarily about the impact of the Verizon iPhone on the smartphone market in the United States, it contains information about iPhone users including age, gender, and household income.

TNS survey: Smartphones gain traction for both businesses and consumers

Details on smartphone platforms in the United States by race and income.

African-Americans, Women and Southerners Talk and Text The Most in the U.S.

Voice and texting numbers organized by state.

Early U.S. iPad Users are Mostly Male, Aged 21 to 44

This information came out shortly after the iPad was released. I’m very interested in seeing newer data. Lots of people say that the iPad is the computer for people who don’t work on computers, but the only data I’ve seen says that the people buying iPads are the same people who buy tech overall. I don’t think it will remain that way, but I’m curious how far the iPad has gone beyond early adopters.

Among Mobile Phone Users, Hispanics, Asians are Most-Likely Smartphone Owners in the U.S.

There is a lot of information that indicates that minority populations are using phones to access the Internet in greater number than caucasians. Mobile phones are being used as leap frog technology for those with lower incomes. Because of this, I believe we will find a lot of hidden innovative uses of mobile phones within these populations. When you don’t have a computer to fall back to, you look at the phone in a different way.

For minorities, new ‘digital divide’ seen

This article in USA Today talks about the negative implications of the fact that minorities are increasingly using mobile phones to access the Internet. On the one hand it is good because they didn’t have ready access before. On the other hand, it presents challenges like filling out job applications on mobile phones and dealing with web sites that are only designed for desktop.

Generations and Gadgets

Pew Research study on technology ownership among age groups.

Rise of the ‘Apps Culture’

App usage demographics

Mobile web metrics

Back in early 2008 when Google created an iPhone optimized version of their search engine, one of the Google representatives justified the decision to develop a special version by saying, “It’s about usage. Not unit.”

When you’re looking at mobile web statistics, you’re looking at usage patterns to try to make decisions about what you need to support.

Unfortunately, nearly every public source of data about mobile web usage is problematic for reasons I’ll list below. The only data that is really useful is your own data about what your customers are using and what traffic your web site gets. And even the latter can be problematic.

If your site has a crummy mobile experience because it is slow or has requires flash, then current traffic to your site is likely not indicative of what will happen when you have a mobile optimized site.

What these stats are good for

• Trying to understand what phones and browsers are being used on the mobile web.
• Understanding how people are using the mobile web.

What to watch for when you use these stats

• Technical problems may cause mobile usage to be under reported. Many web analytics packages require javascript to function. Many mobile phones don’t support javascript or even if they do, the javascript can be take too long to process on a device and fail before it can report back to the analytics server.

  Nearly every analytics engine provides a server side alternative that should be used to get accurate mobile information, but many sites owners don’t implement them or don’t implement them correctly. When looking at aggregate data about mobile usage, you have to wonder how much the data is skewed by this fundamental problem.

• To expand on that previous point for a moment, PPK has been providing reports from StatCounter which is mentioned below. On a mailing list for mobile web, Luca Passani, the lead developer of WURFL, said that he had “4 million lines of logs from a major social network” and that his analysis of those logs showed Openwave at 8% of traffic and NetFront at over 12%. Unfortunately, he can’t share the source of the logs. What do you do with this information? I think you have to look at multiple sources for common elements and then get your own data from your own site and customers.
• Mobile web usage of non-mobile optimized sites is unlikely to tell you much about what the usage will look like when a site is mobile optimized. Most of the aggregate analytics information lumps desktop and mobile web sites together in the reports.
• And to beat a dead horse, here is a great article on Why You Should Take Mobile Web Traffic Statistics With A Grain of Salt

Mobile web metrics sources

StatCounter ( StatCounter Global Stats Reports | Press releases )

The interactive reporting tool for StatCounter allows you to look only at mobile browser usage. You can narrow the usage by country. For all of its flaws, it is only one of two sources that allows you to look at real time data over a large numbers of sites in every geography.

Quirksmode ( Market share blog posts | Jan 2011 data )

Quirksmode is the blog of web guru PPK. PPK publishes monthly reports based on StatCounter data. Every quarter he will dig into the data deeper to compare countries. His recap on 2010 mobile browser stats explains his plans.

Clicky Web Analytics ( Mobile web browsers market share)

Clicky is the other source in addition that StatCounter that allows you to inspect traffic by mobile browser. Unfortunately, it doesn’t identify as many browsers so 14% of traffic falls into the “other” browser category. I also suspect the service requires javascript and suffers from the same problem as StatCounter. I believe StatCounter has a wider reach and more accurate numbers.

Percent Mobile ( Blog | USA Mobile Web Overview – Sept 2010 )

Percent Mobile is a cool mobile web analytics service. They occasionally publish numbers and infographics from their aggregate data. They also have a good post explaining why Blackberry web usage in the USA is often underreported.

Bango ( Press releases | Blog | Q2 2010 Mobile Web Statistics

Bango provides analytics and payment systems for mobile. They’ve been at it for quite some time. While they don’t publish aggregate data all of the time, when they do publish it, I pay attention. My assumption is that because the value of their analytics comes from being able to identify mobile traffic and their relationship with carriers, that their analytics data is dominated by mobile sites and not desktop sites. BTW, Bango is a service more people should consider because of the relationship with carriers. That relationship allows them to uniquely identify users in a way that other analytics services cannot.

Opera ( State of the Mobile Web Monthly Report )

Opera publishes monthly information on usage of the Opera Mini browser.

Quantcast ( Inside Quantcast (Blog?) | August 2010 Mobile OS Share )

Quantcast is an audience measurement company. They have a helpful post that explains their mobile web measurement methodology. Quantcast also provided an extremely detailed look at 2009 mobile web traffic in a 35 page report. Let’s hope they do the same for 2010.

Ground Truth ( Mobile Internet Usage Builds Throughout the Day )

Ground Truth provides mobile measurement tools by gathering data from carriers. They occasionally publish data on their blog. For example, a recent post showed that “32 percent of page views occur between 7 p.m. and midnight, peaking at 9 p.m.“

Device Atlas ( Device Atlas Data Explorer )

Device Atlas doesn’t provide usage data, but what does provide is a data explorer that can be used to look at the characteristics of mobile devices. What to know what percentage of Blackberry phones have a 240 pixel screen? Match those two properties in the data explorer to find out. Keep in mind that Device Atlas is telling you how many Blackberry models have a 240 pixel screen, not how many people are using those phones right now. Still, this is great resource if you’re trying to determine mobile device classes.

Tera-WURFL ( Tera-WURFL Explorer )

This isn’t strictly a metrics resource. Instead, it allows you to enter a user agent string and see what information WURFL has on file for that device.

Comscore ( Dec 2010 Market Share Report )

With every survey that Comscore publishes, they also publish information on the percentage of mobile phone subscribers in the United States that are accessing the mobile web.

Mobile web articles I find interesting

Like the demographic information, I’ve bookmarked some one off articles that are interesting, but I can’t call them a source for mobile web data because they’ve only published one or two pieces of information.

Mobile Web Usage: Smartphone Drives 600% Growth; BlackBerry Takes Lead, Wi-Fi Access Going Strong

This is interesting to me because Bango has always shown more Blackberry usage than other analytics companies. This was from Feb 2010, but at that time, Blackberry was the top web browser client in their network which you don’t see in other reports. Also, 600% growth is insane.

BlackBerry overtakes Apple in Mobile Wars

More recent data from StatCounter indicating that Blackberry caught up in web browsing. Blackberry has always had a fairly large base and unlimited data plans. The only thing holding people back from browsing the web more was the horrid browser. With Blackberry 6, the browser is now webkit-based and consequently Blackberry usage has gone up.

In Defense of Blackberry

Percent Mobile explains why Blackberry is often under reported. If you can’t tell, I like articles that make you question conventional wisdom.

Mobile Web Surfers Visit 24 Sites Per Day!

Also talks about time of day and what types of sites were visited.

PercentMobile Maps – 2nd Quarter 2010

Cool maps showing what devices are being used in what parts of the world.

Orange says UK mobile users prefer browsers to apps

I’ve tired of the mobile web vs. native debate, but I like to keep stuff like this around for when people claim that apps are all that matter and that the web is dead.

Adobe Says People Prefer Mobile Web, Not Apps

“Respondents favored mobile Web experiences over apps in the products & shopping and media & entertainment categories. 66% said they prefer mobile Web to apps (34%) in these categories.” Download the full report.

Lack of Standardization Around Mobile Web Conventions Presents Hurdles for Mobile Publishers

Talk about an understatement. Everything on the mobile web lacks standardization. This report though looks at mobile web domain naming conventions.

Tumblr Mobile OS web-browsing share

Marco published some data on what Tumblr sees on its network. Data is from May 2010

Advertising networks reports

A few of the mobile advertising companies publish reports on what devices they see on their networks. There are some interesting things that can be found in these reports. At the same time, I feel like the data from these reports is commonly either misunderstood or misused.

The reports are most useful when people take them for what they are. They have inherent sampling bias because every advertising network has some sort areas where they do better and where they don’t. When they offer ads both on the mobile web and inside native apps, the reports are going to skew heavily towards platforms with robust app ecosystems.

The worst data comes from when people try to infer more from the reports than is possible or when the advertising networks use their own networks to do a survey of users.

BTW, two of the ad networks that used to provide information on a regular basis—AdMob and Quatrro Wireless—no longer provide reports as they’ve been bought by Google and Apple respectively.

What these stats are good for

• Some sense of the relative numbers of devices being used in different geographies.
• The reach of advertising networks if you’re trying to decide which to use.

What to watch for when you use these stats

• As mentioned above, the networks all have some sort of bias. Figuring out what it is can be difficult.
• Beware networks that offer advertising both inside apps and on the mobile web. Usually these networks will only offer advertising inside apps on a couple of platforms (e.g., iPhone and Android) which means those platforms will account for more impressions.
• Surveys that solicit participants via the ad network that don’t have someone working to balance the data with known demographics are likely to be inaccurate. This is why when companies do any sort of surveying, they have to know the demographics and weight the results to match the complexion of the audience. I’ve seen studies that ask people who responded to ads inside apps how many apps they had installed. By definition, this excludes people who either don’t use apps or don’t use apps that feature advertising on that network.

Advertising network report sources

Millennial Media ( Mobile Mix | S.M.A.R.T. Report | State of the Apps Industry )

Millennial Media is my favorite advertising network report. They are independent. They claim to reach of 80% of the mobile web. And they publish reports monthly. Plus, there are interesting things to find in the reports. For example, the number 9 mobile device in their January 2011 Mobile Mix report is the Samsung Freeform. What’s that device? Well, it’s not Android, Blackberry, or Symbian. It’s a feature phone with a decent browser available with unlimited voice, text and web on MetroPCS for $40/month. Interesting, huh?

JiWire ( JiWire Mobile Audience Insights Report Quarterly )

JiWire provides ads for WiFi hotspots. Lots of traffic through the network.

InMobi ( InMobi Research )

Reports on their network separated by region. Top platforms, devices, and manufacturers.

Mobclix ( Moblix Index )

Monthly infographics based on Mobclix data.

Chitika ( Chitika Insights )

Chitika’s research group chimes in on a lot of different topics. Recent posts have covered the Google/Bing search bar controversy and whether or not Chrome OS is a viable desktop operating system. They look for ways to test these theories using their ad network data. This can lead to good insights, but it can also lead to high profile mistakes such as when they attempted to use their ad network to estimate the number of iPad purchases—even going so far as to create a real time tracker—only to find the numbers were way off when Apple announced real sales numbers.

Mobile Advertising Networks Compared

Infographic comparing the various networks in December 2010.

mobiThinking guide to mobile advertising networks (2011)

Data and profiles on the various networks to help you pick a network.

Apps metrics

Because of the popularity of app stores and the success developers have had selling apps, there is a LOT of information about app usage. Much of it comes from services providing analytics to app developers.

What these stats are good for

• Understanding how people are using apps..
• Helping to determine your app strategy.

What to watch for when you use these stats

• Like all of the other statistics, understanding the source of the data. Is it a survey? What was the methodology? What platforms were included in the source data?

App metric sources

Distimo ( Publications | App Stores)

Most comprehensive monthly report covering the major mobile app stores. They also keep track of all of the available app stores.

Wireless Industry Partnership (WIP) ( App Store Reports )

WIP helps connect developers with carriers and handset manufacturers. They recently started tracking all of the app stores available. In addition to being able to find app store info on the WIP site, they provide a monthly report.

Flurry ( Flurry Blog | Android Special Report: Is Samdroid the new Wintel?

Flurry provides analytics for iOS, Android, Windows Phone, Blackberry and Java ME apps. They also survey developers that are using their analytics on a regular basis and publish the results.

Localytics ( Localytics Blog )

Competitor to Flurry. Their blog has had some great insights lately including the fact that “26% of apps downloaded in 2010 were used just once.”

Xyologic ( Facebook | Twitter )

Xyologic provides insight for developers and businesses. Unless you are a customer, it is easiest to follow them on Twitter or Facebook to learn about new articles or research.

App Genome Project

This is a fairly new report. It says, “The App Genome Project is the world’s largest mobile application dataset created to map the anatomy of mobile applications across multiple mobile platforms and app markets. To date, the project has analyzed more than 500,000 Android and iOS applications.”

Sizing up the Global Mobile Apps Market

Report by Chetan Sharma on the app market.

AndroLib ( Android Marketplace Metrics )

Number of apps, paid vs. free, total downloads in the Android Market.

148Apps.biz ( iPhone App Store Metrics

Number of app, paid vs. free, total downloads, most popular categories, etc.

Urban Airship ( 2010 Mobile App Developer Survey Results )

Urban Airship provides push notification and in app purchasing tools. They published a developer survey in December that was interesting. They also have a unique perspective on what is happening when it comes to push notifications and in app purchases. Thus far they haven’t published an reports, but I’m keeping my eye out for them. [Full disclosure: I'm on the board of advisors for Urban Airship and keep bugging them to publish data. ]

Pew Research ( Rise of the ‘Apps Culture’ )

Pew research into app usage and culture

Comscore ( Dec 2010 Smartphone Report )

Each smartphone report contains a note on the percentage of US phone users who download apps.

Mobclix ( Mobclix Index )

Mobclix monthly infographics have recently included the Monthly Value of an App User and the Android Marketplace.

Other fun sources

There are some resources that span multiple categories but need to be included somewhere. They go here.

Mary Meeker’s Internet Trends ( Top 10 Mobile Internet Trends Feb 2011 )

Mary Meeker was a long time analyst for Morgan Stanley and published yearly reports on Internet trends. She now works for venture capital firm Kleiner Perkins. Her slide decks are legendary for their density and information. Must read.

Tomi Ahonen ( An 8 Segment Model to Analyze Smartphone Market, Consumers and Handsets | All the Numbers, All the Facts on Mobile the Trillion-Dollar Industry. )

I listed Tomi in the market share section because he talks about market share most often. But Tomi covers a lot of other areas when it comes to mobile. He is some times crazy and always too verbose, but there is a lot of good stuff on his blog. In particular, I wanted to highlight his post called An 8 Segment Model to Analyze Smartphone Market, Consumers and Handsets There are few things more frustrating for me than reading someone write about the mobile market assuming that everyone is evaluating phones the same way there are. I’m not saying Tomi’s model is correct, but reading it helps you understand that a certain percentage of people are going to make finding a phone with the best possible keyboard a priority even if the keyboard doesn’t matter to you.

Mobile Phone Development by Simon Judge ( Mobile Market Research )

Simon’s blog tracks many of the studies that come out. His Mobile Market Research page contains an archive of market share and other information going back several years.

Yiibu ( Mobile Web Reference )

Yiibu is a small development company led by Stephanie and Brian Rieger. Their Mobile Web Reference page contains quite a few resources. In fact, had I remembered they had this page, I might have been saved from writing this epic post.

My Pinboard Bookmarks ( Statistics | Demographics )

I’ve bookmarked a lot of mobile articles. You can follow new entries on Pinboard.

Which stats should you care about?

Depending on what type of business you have and your role, the mobile statistics that you care about are different. Figuring out what questions matter to you is the first step in finding the statistics that will help you make decisions.

App developers

App developers need to figure out where they have the best chance to sell their apps or make money from advertising. In particular, developers are often trying to determine which platform to develop for first.

Because the factors that make an app successful are not necessarily the same ones that make a platform dominate, market share and sales numbers don’t matter as much. Developers will probably weigh the benefits of building something for an established market like iOS where development is easier but the competition is more intense with the opportunities of new markets like Windows Phone 7.

App developers need to look at the app store metrics, advertising data and demographic information (particularly for things like adoption of location-based services).

Web developers

Web developers are accustomed to being able to look at high-level statistics on browser market share and screen resolution and make educated decisions about what platforms they need to support. If they are working on an existing site, there is likely existing analytics that can be used.

When it comes to mobile web, there aren’t the same easy answers. Existing analytics on a desktop site are not going to provide much insight into how a site will be used once it is mobile optimized. Some analytics systems don’t even handle mobile web very well.

Aggregate information on mobile web usage is also problematic because it requires site owners to add server side alternatives to the normal javascript-based analytics code. Finally, global numbers on mobile browser usage may not match the target customer base.

In addition to reviewing mobile web metrics, web developers should also look at demographics to try to match their target audience to the devices they are likely to use. The installed base of phones can also be useful.

The ultimate data comes from the customers of a web site or service. The more you can learn about what devices they are using and how they are using them, the better you can target your efforts.

Marketing

From a pure marketing perspective, you’re going combine your objectives with demographics, installed base and advertising information to determine where to spend your money.

Investors

They should obviously look at financial information, but looking at trends in sales market share also makes sense as an indicator of how companies are competing against others in the market.

Your role here

The point of this list wasn’t to be definitive about what anyone in particular should be concerned with. The data that matters to you should be determined by your interest and objectives when it comes to mobile.

I track a lot of mobile statistics, but I know the ones I care about and why I care about them. They matter because of the type of work I do and my theories on what will happen in the mobile market. (And yes, I’ll write about them in a separate post soon).

But the data that matters to you may not be the ones that matter to someone else. Assuming they should care about the same things you do is the most common mistake I see people make when trying to understand what is happening in the mobile market.