Customers have to specifically decide on a feature set, not just on the platform

It’s not enough to get “an Android phone”. There are two major differentiators on the Android platform that requires customers to look close to really get what they want: 1) the OS version and 2) the specific device capabilities. These two are interconnected (a device usually only comes with one specific OS version), but two devices with similar hardware can perform quite differently with different OSses.

The major differences customers can experience are along these lines (in no specific order):

• screen size
• networks supported (3G/WiFi,GSM)
• keyboard / touchscreen
  • multi-touch or just single-touch
    • (in the multi-touch case there are different qualities of multi-touch as well (number of simultaneous touches supported, robustness of detection)
• camera
  • sensor quality
  • flash (yes/no/type)
  • front-facing camera (yes/no)
• GPS (yes/no)
• pre-installed apps*
• fundamental look and feel of the apps on the device*
• availability of fundamental apps like navigation*
• availability of tethering
• size of internal memory
  • this is a big issue because pre-2.2 devices cannot install applications on SD cards and this limits the amount of installable apps dramatically
• Google certification*
• enterprise security features *

the items marked with a * will be subject to a future post because they require more detailed discussion

Many of these options that are not prominently advertised (and as such taken as a platform capability) make a difference for the applicability of your Android device (tethering? fundamental look and feel?). Also, all these options may lead to a Paradox of choice situation.

Now, to me it seems that the mobile devices market is mostly defined through devices, not so much through platforms, but that may be changing now. Apple delivers the iOS for different devices and Motorola calls it’s devices the Droids, so platform may be important.

The questions that remains to be answered: What are the defining properties of the Android platform from a customer perspective?

The Samsung mail client

Samsung has put their own email client with IMAP/POP3 support on the phone. And I’ve never used an email client with so many fundamental flaws:

• it considers all mail it has not read itself to be unread on IMAP. (Yes, IMAP!)
• you cannot copy text from received emails (!!!)
• it does not support threading
• folders are shown as an horizontal bar at the top. This is not helpful if you have 50+ folders
  • oh, and you cannot move/copy mails to folders anyway
• the “new mail” notification does not show subjects, only number of mails received
• responding to mail does a fullquote and puts the text to the top; and no, there’s no way to do it another way

And I forgot, it looks really ugly.

Fortunately there’s K9Mail on the Android market that does most of these things better. But for an out-of-the-box experience (how many people exactly will be spending time looking for alternative clients) this is really bad. You can do better, Samsung.

Samsung's Mail app

1. Why? (What is their motivation for offering the service?)
2. What’s not on the table (yet)? (What are some possible additional uses of the service (or the data it produces) which are not obvious today or even explicitly denied by the provider?)

Both questions often don’t have definite answers because one is usually acting out of imperfect knowledge. That’s why I’m asking you, dear readers, to be creative and come up with some answers to them in the comments. I’ll start with some ideas of my own…

Why?

• As Google earns its money on the web, what’s good for the web is also good for Google. Faster loading of web pages is obviously in Google’s interest. Asynchronous HTTP calls (AJAX) used by many web pages (and especially by Google’s services) affect responsiveness of web applications and as such directly influence the user experience. (I’m not sure how big the number of DNS requests initiated by AJAX calls is, as they usually refer to a small number of known addresses).

What’s not on the table (yet)?

• Google has an interest in controlling the application layer part of how the web works (the introduction of SPDY points in a similar direction). This enables them to influence the technology used in the web and to push forward technology that most fits their needs. One should be aware that this behavior could lead to Google gaining a dominant role in deciding on how web protocols work.
• What can you actually do with DNS request data? You have the requesting IP address and the host name requested. You cannot use cookies for identification as in the web. NAT prevents clear identification of the source of some requests (IPv6 will eventually get rid of NAT and solve this “problem”). But hey, this is Google! They also know a good part of what goes on in the web after the DNS request has been made. If there’s a DNS requests for domain A by client address X and an HTTP request for the IP address of domain A by the same client X (which Google may now be able to identify using cookies; using Google Analytics, Google may be able to correlate requests for a web page and the corresponding request for the Google Analytics), you can actually identify clients using DNS. What does Google gain by that? I’m actually not sure. Google can relate activities going on outside the web (mail, news, etc.) and extend their profiling abilities. Monitoring behavior outside the web might be remotely useful for Google, but after all, they’re a web company.

Intermediate conclusion

I think making the web more usable by increasing responsiveness and gaining a little influence on the web architecture might be good enough reasons for Google to offer a DNS service. But there’s probably so much more to Google’s rationale. What might the data Google gathers be useful for? They are all about data, there has to be something in there for them. What are your ideas?